Fix constant-folding of ROW(...) IS [NOT] NULL with composite fields.
The SQL standard appears to specify that IS [NOT] NULL's tests of field nullness are non-recursive, ie, we shouldn't consider that a composite field with value ROW(NULL,NULL) is null for this purpose. ExecEvalNullTest got this right, but eval_const_expressions did not, leading to weird inconsistencies depending on whether the expression was such that the planner could apply constant folding. Also, adjust the docs to mention that IS [NOT] DISTINCT FROM NULL can be used as a substitute test if a simple null check is wanted for a rowtype argument. That motivated reordering things so that IS [NOT] DISTINCT FROM is described before IS [NOT] NULL. In HEAD, I went a bit further and added a table showing all the comparison-related predicates. Per bug #14235. Back-patch to all supported branches, since it's certainly undesirable that constant-folding should change the semantics. Report and patch by Andrew Gierth; assorted wordsmithing and revised regression test cases by me. Report: <20160708024746.1410.57282@wrigleys.postgresql.org>
Showing
- doc/src/sgml/func.sgml 148 additions, 51 deletionsdoc/src/sgml/func.sgml
- src/backend/executor/execQual.c 15 additions, 0 deletionssrc/backend/executor/execQual.c
- src/backend/optimizer/util/clauses.c 9 additions, 4 deletionssrc/backend/optimizer/util/clauses.c
- src/test/regress/expected/rowtypes.out 54 additions, 0 deletionssrc/test/regress/expected/rowtypes.out
- src/test/regress/sql/rowtypes.sql 24 additions, 0 deletionssrc/test/regress/sql/rowtypes.sql
Loading
Please register or sign in to comment