Horton

Re: Catalog domain not-null constraints

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Dean Rasheed <dean.a.rasheed@gmail.com>, jian he <jian.universality@gmail.com>, Aleksander Alekseev <aleksander@timescale.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Alvaro Herrera <alvherre@alvh.no-ip.org>, vignesh C <vignesh21@gmail.com>
Date: 2024-03-21T14:30:10Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix ALTER DOMAIN NOT NULL syntax

  2. Catalog domain not-null constraints

  3. Add tests for domain-related information schema views

Peter Eisentraut <peter@eisentraut.org> writes:
> <canofworms>
> A quick reading of the SQL standard suggests to me that the way we are 
> doing null handling in domain constraints is all wrong.  The standard 
> says that domain constraints are only checked on values that are not 
> null.  So both the handling of constraints using the CHECK syntax is 
> nonstandard and the existence of explicit NOT NULL constraints is an 
> extension.  The CREATE DOMAIN reference page already explains why all of 
> this is a bad idea.  Do we want to document all of that further, or 
> maybe we just want to rip out domain not-null constraints, or at least 
> not add further syntax for it?
> </canofworms>

Yeah.  The real problem with domain not null is: how can a column
that's propagated up through the nullable side of an outer join
still be considered to belong to such a domain?

The SQL spec's answer to that conundrum appears to be "NULL is
a valid value of every domain, and if you don't like it, tough".
I'm too lazy to search the archives, but we have had at least one
previous discussion about how we should adopt the spec's semantics.
It'd be an absolutely trivial fix in CoerceToDomain (succeed
immediately if input is NULL), but the question is what to do
with existing "DOMAIN NOT NULL" DDL.

Anyway, now that I recall all that, e5da0fe3c is throwing good work
after bad, and I wonder if we shouldn't revert it.

			regards, tom lane