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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
