On Tue, Sep 3, 2013 at 09:43:14PM -0400, Tom Lane wrote:
> Bruce Momjian <br...@momjian.us> writes:
> > This has made me adjust my goal and change it so SELECT ROW(NULL) IS
> > NULL returns true, and any further nesting returns false.
>
> AFAICS, the only good argument for breaking backwards compatibility here
> is if you can convince people that the new behavior is more conformant to
> the SQL spec. Where's the chapter and verse that argues for this
> interpretation?
The SQL03 standard in section 8.7, table 14, says "degree 1: null" and
"degree > 1: all null". Does that mean they are considering nested rows
as degree > 1, or is that the number of values in the row? A footnote
says:
For all R, "R IS NOT NULL" has the same
result as "NOT R IS NULL" if and only if R is of
degree 1.
which seems to support the idea that degree is the number of values,
meaning they don't discuss nesting.
> And I will say once more that a patch that affects only the behavior of
> eval_const_expressions can be rejected on its face. That code has to be
> kept in sync with the behavior of execQual.c, not just whacked around by
> itself. And then there are the NOT NULL constraint cases to worry about.
I thought execQual.c was already not recursing so I didn't see a need to
change that.
I could not figure out how to test a NOT NULL constraint for nesting.
What is driving my research here is that our current behavior is really
not documentable.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
