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

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: revert behavior of IS NULL on row types
Date: 2016-07-23 00:25:10
Message-ID: CAKFQuwYauWmr4HqXa-gpOcM1QxMuQ_Xp8Cn=cdh-FhSbcqG15Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 22, 2016 at 8:04 PM, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
wrote:

> >>>>> "David" == David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Gierth 2016-07-23 00:45:32 Re: Proposal: revert behavior of IS NULL on row types
Previous Message Andrew Gierth 2016-07-23 00:21:19 Re: Proposal: revert behavior of IS NULL on row types