Re: Domain checks not always working when used in compound type - Mailing list pgsql-admin

From Tom Lane
Subject Re: Domain checks not always working when used in compound type
Date
Msg-id 3236280.1703879366@sss.pgh.pa.us
Whole thread Raw
In response to Domain checks not always working when used in compound type  (Holger Jakobs <holger@jakobs.com>)
Responses Re: Domain checks not always working when used in compound type
List pgsql-admin
Holger Jakobs <holger@jakobs.com> writes:
> -- Using the domain within a compound type. The NOT NULL constraint 
> should be
> -- inherited from the domain, therefore not repeated here for column a.
> CREATE TYPE compound_ab AS (
>    a    domain_a,
>    b    varchar(10)
> );

You are assuming in effect that a simple NULL value for a composite
type is the same thing as ROW(NULL, NULL).  They are not quite the
same, and one way in which they are not is that we don't consider
field-level constraints when deciding if a simple NULL value is legal
for the composite -- it always is.  Thus

regression=# select null::compound_ab;
 compound_ab 
-------------
 
(1 row)

regression=# select row(null, null)::compound_ab;
ERROR:  domain domain_a does not allow null values

The SQL spec itself is pretty schizophrenic about whether ROW(NULL, NULL)
is equivalent to bare NULL.  This is how we've chosen to interpret it.
I'll freely admit that there's some implementation considerations
involved in that choice, but we're unlikely to revisit it.

If you don't want things to work like this, you could attach a NOT
NULL constraint to the test1.ab column (as well as having the domain
constraint).

            regards, tom lane



pgsql-admin by date:

Previous
From: Holger Jakobs
Date:
Subject: Domain checks not always working when used in compound type
Next
From: Holger Jakobs
Date:
Subject: Re: Domain checks not always working when used in compound type