On Fri, Jul 22, 2016 at 1:39 PM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> On Fri, Jul 22, 2016 at 2:13 PM, Tom Lane <tgl@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
