From: | Vik Fearing <vik(at)postgresfriends(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:08:12 |
Message-ID: | 8fbc4e88-036a-45cc-bb20-eab044a73013@postgresfriends.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/23/23 18:53, Tom Lane wrote:
> 1. Domains are data types, with the proviso that NULL is always a valid
> value no matter what the domain constraints might say.
> Implementation-wise, this'd just require that CoerceToDomain immediately
> return any null input without checking the constraints. This has two big
> attractions:
> (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. The intention is, in my
view, clearly to check the constraints upon casting. What other
explanation is there since the result type is still the domain's base
type[*]?
[*] In the standard, not in our superior implementation of it.
--
Vik Fearing
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2023-10-23 21:17:22 | Re: LLVM 16 (opaque pointers) |
Previous Message | Tom Lane | 2023-10-23 21:04:08 | Re: Add trailing commas to enum definitions |