Re: Proposal: revert behavior of IS NULL on row types
От | Thomas Munro |
---|---|
Тема | Re: Proposal: revert behavior of IS NULL on row types |
Дата | |
Msg-id | CAEepm=3S5TjiTs1gSr5ujgN-UenCAm25hhW_VbvouCD_AF-tNQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal: revert behavior of IS NULL on row types (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Proposal: revert behavior of IS NULL on row types
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: