Re: PostgreSQL domains and NOT NULL constraint - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PostgreSQL domains and NOT NULL constraint
Date
Msg-id 431063.1698096089@sss.pgh.pa.us
Whole thread Raw
In response to Re: PostgreSQL domains and NOT NULL constraint  (Vik Fearing <vik@postgresfriends.org>)
List pgsql-hackers
Vik Fearing <vik@postgresfriends.org> writes:
> On 10/23/23 18:53, Tom Lane wrote:
>> (1A) It satisfies the plain language of the SQL spec about 
>> how CAST to a domain type behaves.

> I agree with all of your proposal, except for this part.  I think the 
> shortcut in the General Rules of <cast specification> is an oversight 
> and I plan on submitting a paper to fix it.

Yeah, it might be a bug in the spec, but if so the bug has been there
since SQL92 without anyone noticing.  SQL92 has GR2 as

         2) Case:

            a) If the <cast operand> specifies NULL or if SV is the null
              value, then the result of the <cast specification> is the
              null value.

SQL99 revised the text some, but without changing that outcome.
Then in SQL:2003 they doubled down on the point:

    a) If the <cast operand> specifies NULL, then TV is the null value and
    no further General Rules of this Subclause are applied.

    b) If the <cast operand> specifies an <empty specification>, then TV
    is an empty collection of declared type TD and no further General
    Rules of this Subclause are applied.

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

You're suggesting that nobody noticed that this wording requires NULLs
to skip the domain checks?  Maybe, but I think it must be intentional.
I'll await the committee's reaction with interest.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: LLVM 16 (opaque pointers)
Next
From: Alec Lazarescu
Date:
Subject: Re: Creating foreign key on partitioned table is too slow