From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Vik Fearing <vik(at)postgresfriends(dot)org> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, vignesh C <vignesh21(at)gmail(dot)com> |
Subject: | Re: Catalog domain not-null constraints |
Date: | 2024-03-21 23:17:28 |
Message-ID: | 789947.1711063048@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 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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2024-03-21 23:20:11 | Re: Regression tests fail with musl libc because libpq.so can't be loaded |
Previous Message | Melih Mutlu | 2024-03-21 23:07:56 | Re: Flushing large data immediately in pqcomm |