Re: strange IS NULL behaviour

On Tue, Sep 3, 2013 at 09:43:14PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +