On Fri, Jul 22, 2016 at 1:39 PM, David G. Johnston <david.g.johns...@gmail.com> wrote: > On Fri, Jul 22, 2016 at 2:13 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> There is a rather squishy question as to whether NULL::composite_type >> should be semantically equivalent to ROW(NULL,NULL,...)::composite_type. >> If it is, then the SELECT should have failed before even getting into the >> plpgsql function, because ROW(NULL,NULL) is surely not a valid value of >> type c. The SQL standard seems to believe that these things *are* >> equivalent (at least, that was how we read the spec for IS [NOT] NULL). >> > > I dislike that they are considered equal in various circumstances but if > that's we are guided toward c'est la vie.
Not sure we are guided there. Currently we follow the spec specifically with the IS NULL operator but not in other cases. For example. postgres=# select row(null, null) is null; ?column? ────────── t postgres=# select coalesce(row(null, null), row(1,1)); coalesce ────────── (,) Seem not to agree (at all) since I'm pretty sure the spec defines coalesce in terms of IS NULL. The basic problem we have is that in postgres the record variable is a distinct thing from its contents and the spec does not treat it that was. For my part, I think the spec is totally out to lunch on this point but we've been stuck with the status quo for quite some time now -- there's been no compelling narrative that suggests how things should be changed and to what. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
