Re: Catalog domain not-null constraints

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-22 00:46:52
Message-ID: 804552.1711068412@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/22/24 00:17, Tom Lane wrote:
>> Vik Fearing <vik(at)postgresfriends(dot)org> writes:
>>> 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?

> Haven't we (postgres) had bug reports of similar age?

Well, they've looked it at it since then. SQL99 has

c) If SV is the null value, then the result is the null value.

SQL:2008 and later have the text I quoted:

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

I find it *extremely* hard to believe that they would have added
that explicit text without noticing exactly which operations they
were saying to skip.

> Anyway, I will bring this up with the committee and report back. My
> proposed solution will be for CAST to check domain constraints even if
> the input is NULL.

Please do not claim that that is the position of the Postgres project.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2024-03-22 00:51:39 Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs
Previous Message Paul Jungwirth 2024-03-22 00:35:53 Re: SQL:2011 application time