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: Vik Fearing <vik@postgresfriends.org>
Cc: Peter Eisentraut <peter@eisentraut.org>, 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-21T23:17:28Z
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

Vik Fearing <vik@postgresfriends.org> writes:
> On 3/21/24 15:30, Tom Lane wrote:
>> 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 don't see how you can infer this from the standard at all.

I believe where we got that from is 6.13 <cast specification>,
which quoth (general rule 2):

    c) If SV is the null value, then the result of CS is the null
    value and no further General Rules of this Subclause are applied.

In particular, that short-circuits application of the domain
constraints (GR 23), implying that CAST(NULL AS some_domain) is
always successful.  Now you could argue that there's some other
context that would reject nulls, but being inconsistent with
CAST would seem more like a bug than a feature.

> As also said somewhere in that thread, I think that <cast specification> 
> short-cutting a NULL input value without considering the constraints of 
> a domain is a bug that needs to be fixed in the standard.

I think it's probably intentional.  It certainly fits with the lack of
syntax for DOMAIN NOT NULL.  Also, it's been like that since SQL99;
do you think nobody's noticed it for 25 years?

			regards, tom lane