Re: BUG #7808: unnest doesn't handle nulls in array of composite typescorrectly - Mailing list pgsql-bugs

From Andrew Gierth
Subject Re: BUG #7808: unnest doesn't handle nulls in array of composite typescorrectly
Date
Msg-id 87eg6koste.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: BUG #7808: unnest doesn't handle nulls in array of composite typescorrectly  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #7808: unnest doesn't handle nulls in array of composite typescorrectly
List pgsql-bugs
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 Tom> I do not see how you can propose this, which creates an explicit
 Tom> equivalence between a plain null and an all-nulls row, and
 Tom> simultaneously advocate that we change IS NULL to remove its
 Tom> treatment of those things as equivalent.

Because the proposal to change IS NULL is a discussion point that I'm
not dogmatically committed to.

 Tom> I think the theory behind the existing code here is that if the
 Tom> SRF wants its output to be interpreted as an all-nulls row, it can
 Tom> perfectly well return an all-nulls row.  I wonder whether we
 Tom> should address this by adjusting unnest's behavior instead.

One problem with changing unnest() is that it makes the operation
array(select unnest(a)) return an array that's not equal to the original
one (and which takes up a lot more space if there are many nulls). This
is far more likely to break existing code than simply allowing what was
previously an error case to work.

--
Andrew (irc:RhodiumToad)

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #7808: unnest doesn't handle nulls in array of composite typescorrectly
Next
From: Stephen Frost
Date:
Subject: Re: BUG #14228: replication slot catalog_xmin not cleared on slot reuse