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