Re: PostgreSQL domains and NOT NULL constraint

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vik Fearing <vik(at)postgresfriends(dot)org>
Cc: Erki Eessaar <erki(dot)eessaar(at)taltech(dot)ee>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: PostgreSQL domains and NOT NULL constraint
Date: 2023-10-23 21:21:29
Message-ID: 431063.1698096089@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Vik Fearing <vik(at)postgresfriends(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alec Lazarescu 2023-10-23 21:39:59 Re: Creating foreign key on partitioned table is too slow
Previous Message Thomas Munro 2023-10-23 21:17:22 Re: LLVM 16 (opaque pointers)