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 01:05:49
Message-ID: CAKFQuwaOiJ_6yNq2v2y9kQttN7VEg3exses1SsOzo0zm4G5V1w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Friday, July 22, 2016, 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
> <javascript:;>> writes:
>
> >> Prohibiting IS NOT NULL is not on the cards; it's very widely used.
>
> David> ​Yet changing how it behaves, invisibly, is?
>
> Did you mean prohibiting it only for composite-type args? It's obviously
> widely used for non-composite args.
>
> 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.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2016-07-23 01:14:25 Re: Re: Unexpected memory usage for repeated inserts within plpgsql function
Previous Message Andrew Gierth 2016-07-23 00:45:32 Re: Proposal: revert behavior of IS NULL on row types