Re: strange IS NULL behaviour

I wrote:
> 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.

Hmm ... actually, it's already not in sync, because:

regression=# create table tt (x int);
CREATE TABLE
regression=# insert into tt values(null);
INSERT 0 1
regression=# select row(x) from tt;
row
-----
()
(1 row)

regression=# select row(row(x)) from tt;
row
--------
("()")
(1 row)

regression=# select row(row(row(x))) from tt;
row
--------------
("(""()"")")
(1 row)

There's certainly no excuse for this behaving differently from the cases
with a simple constant NULL. So I'm a bit inclined to say that we should
rip out the special case in eval_const_expressions, not make it even less
self-consistent. It's possible to argue that existing applications won't
be too sensitive to the behavior of the constant cases, but they surely
must be depending on the behavior in the non-constant cases.

regards, tom lane