Re: Proposal: revert behavior of IS NULL on row types

On 7/22/16 8:05 PM, David G. Johnston wrote:
>
> I would expect that >95% of cases where someone has written (x IS NOT
> NULL) for x being a composite type, it's actually a bug and that NOT (x
> IS NULL) was intended.
>
>
> Yeah, it would need to be targeted there. I agree with the numbers and
> the sentiment but it's still allowed and defined behavior which changing
> invisibly is disconcerting.

Yeah, that worries me too... I'm not sure what can be done about it
other than a compatibility GUC (and we know how we love those... :( ).

On the LEFT JOIN scenario, I'm not sure why we should disallow that. Is
that commonly error prone?

BTW, one thing that would be very nice about this is it'd let you do
DECLARE
r_new record := coalesce(NEW,OLD);
r_old record := coalesce(OLD,NEW);

which would be much nicer than how things work today (I'm going on the
assumption that referencing NEW in a DELETE trigger would be legit and
give you NULL with the new semantics, but trying to actually reference
any of it's fields would produce an error).
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461