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

From Thomas Munro
Subject Re: Proposal: revert behavior of IS NULL on row types
Date
Msg-id CAEepm=3S5TjiTs1gSr5ujgN-UenCAm25hhW_VbvouCD_AF-tNQ@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: revert behavior of IS NULL on row types  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal: revert behavior of IS NULL on row types  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On Wed, Jul 27, 2016 at 7:35 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "David G. Johnston" <david.g.johnston@gmail.com> writes:
>> The concept embodied by "NULL" in the operator "IS [NOT] NULL" is distinct
>> from the concept embodied by "NULL" in the operator "IS [NOT] DISTINCT
>> FROM".
>
>> In short, the former smooths out the differences between composite and
>> non-composite types while the later maintains their differences.  While a
>> bit confusing I don't see that there is much to be done about it - aside
>> from making the distinction more clear at:
>> https://www.postgresql.org/docs/devel/static/functions-comparison.html
>
>> Does spec support or refute this distinction in treatment?
>
> AFAICS, the IS [NOT] DISTINCT FROM operator indeed is specified to do the
> "obvious" thing when one operand is NULL: you get a simple nullness check
> on the other operand.  So I went ahead and documented that it could be
> used for that purpose.

By the way, our documentation says that NOT NULL constraints are
equivalent to CHECK (column_name IS NOT NULL).  That is what the SQL
standard says, but in fact our NOT NULL constraints are equivalent to
CHECK (column_name IS DISTINCT FROM NULL).  Should we update the
documentation with something like the attached?

--
Thomas Munro
http://www.enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: to_date_valid()
Next
From: Michael Paquier
Date:
Subject: Re: AdvanceXLInsertBuffer vs. WAL segment compressibility