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