Re: Proposal: revert behavior of IS NULL on row types
От | Tom Lane |
---|---|
Тема | Re: Proposal: revert behavior of IS NULL on row types |
Дата | |
Msg-id | 2774.1469583069@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Proposal: revert behavior of IS NULL on row types (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Список | pgsql-hackers |
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: > On 7/26/16 7:46 PM, Thomas Munro wrote: >> 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? > Couldn't we just fix that instead? For NOT NULL constraints on > composite type columns, create a full CHECK (column_name IS NOT NULL) > constraint instead, foregoing the attnotnull optimization. Maybe. There's a patch floating around that expands attnotnull into CHECK constraints, which'd provide the infrastructure needed to consider changing this behavior. But that's not going to be back-patchable, and as I noted in <10682.1469566308@sss.pgh.pa.us>, we have a problem right now that the planner's constraint exclusion logic gets these semantics wrong. regards, tom lane
В списке pgsql-hackers по дате отправления: