Re: Proposal: revert behavior of IS NULL on row types - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Proposal: revert behavior of IS NULL on row types
Date
Msg-id CAKFQuwYauWmr4HqXa-gpOcM1QxMuQ_Xp8Cn=cdh-FhSbcqG15Q@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: revert behavior of IS NULL on row types  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: Proposal: revert behavior of IS NULL on row types
List pgsql-hackers
On Fri, Jul 22, 2016 at 8:04 PM, Andrew Gierth <andrew@tao11.riddles.org.uk> wrote:
>>>>> "David" == David G Johnston <david.g.johnston@gmail.com> writes:

 >> 2. x IS NOT NULL  if and only if  NOT (x IS NULL)

 David> ​I would rather prohibit "IS NOT NULL" altogether.​ If one needs
 David> to test "NOT (x IS NULL)" they can write it that way.

Prohibiting IS NOT NULL is not on the cards; it's very widely used.


​Yet changing how it behaves, invisibly, is?  I'm tending to agree that status-quo is preferable to either option but if you say change is acceptable I'd say we should do it visibly.

Allowing syntax that is widely used but implementing it differently than how it is being used seems worse than telling people said syntax is problematic and we've chosen to avoid the issue altogether.
 
 >> Whole-row vars when constructed never contain the null value.

 David> ...but what does this mean in end-user terms?​

It means for example that this query:

  select y from x left join y on (x.id=y.id) where y is null;

would always return 0 rows.


​Ok, so I'm pretty sure I disagree on this one too.

David J.

pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: Proposal: revert behavior of IS NULL on row types
Next
From: Andrew Gierth
Date:
Subject: Re: Proposal: revert behavior of IS NULL on row types