Re: PostgreSQL domains and NOT NULL constraint

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

In response to

Responses

Browse pgsql-hackers by date

  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