Accidentally replied to Tom directly. Sending to the list now.
On Sun, Mar 7, 2010 at 9:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Mar 5, 2010 at 5:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> It's arguably a bug, but since we lack consensus on whether NULL and
>>> ROW(NULL,NULL,...) are the same thing, it's difficult to make a
>>> bulletproof case either way.
>
>> Have we or can we somehow document why this happens?
>
> The reason it happens is that the assignment target is a "row" variable,
> meaning that it doesn't have concrete existence as a tuple but is just
> an alias for a list of scalar variables. So there is no way for it to
> represent an atomic NULL; setting each of the individual scalars to NULL
> is possible but the result acts more like ROW(NULL,NULL,...).
I am going to offer a slightly different perspective here. Oleg is
putting casting both the record and row to text before comparing them.
I personally wouldn't necessarily expect this to be safe across
datatypes. Regardless of whether NULL is the same as ROW(NULL), it
seems that it is inherently questionable to rely on textual
representations of different datatypes in such comparisons.
>
> I'm not sure about documenting that. It seems like an implementation
> detail. If we had consensus that the two cases either should or should
> not be distinguishable, we could work towards making that happen; but
> lacking such consensus I'm hesitant to touch it at all.
I am not sure about that. If we have a ROW variable, how do we know,
when we cast it to text, whether or not a given NULL is really a
single NULL or rather a ROW(NULL,NULL....) variable? Absent such
information, how can you be sure that textual representations will be
equal?
It seems to me the fundamental issue here (which might be worth
documenting) is that NEW is not currently a tuple, so textual
representations of NEW and the tuple cannot be guaranteed to be
identical (because the amount of information in the record is greater
than in the row). This seems to be separate from the question of
whether ROW(NULL...) and NULL are the same from a row comparison
viewpoint.
Hope this adds something to the discussion.
Best Wishes,
Chris Travers