Composite type versus Domain constraints. - Mailing list pgsql-general

From James Robinson
Subject Composite type versus Domain constraints.
Date
Msg-id 9b019f528d0da3b16f1d4fc48cc5848d@socialserve.com
Whole thread Raw
Responses Re: Composite type versus Domain constraints.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
I'm trying to experiment with domains and composite types under 8.0.2.
It seems that domain constraints don't fire when the domain is embedded
within a composite type:

---
create domain simple as smallint default 0 constraint limits check
(VALUE IN (0,1,2,3));
create type comp_simple as ( simp_val simple);

create table simple_table
(
    s1 simple,
    s2 comp_simple
);

insert into simple_table values (2, null);    -- works fine -- 2 is legal
value
insert into simple_table values (43, null); -- errors out correctly --
43 fails the constraint test.
insert into simple_table values (null, '(43)'); -- GRR works!!! It'll
let any smallint in. What happened to the constraint?

select * from simple_table;
social=# select * from simple_table;
  s1 |  s2
----+------
   2 |
     | (43)
(2 rows)

----

The 8.0.2 docs for composite types (doc/html/rowtypes.html) mention
using domain types as members of composite types to actually gain
constraint testing capability within composite types used outside of
tables.

We've also tried inverting the relationship between the domain and
composite type:
----
social=# create type simple as ( val int2);
CREATE TYPE
social=# create domain simple_checked as simple default '(0)'
constraint limits check ((VALUE).val IN (0,1,2,3));
ERROR:  "simple" is not a valid base type for a domain
social=#


Any way I can get a composite type with constraint tests? I need an
additional type with a separate oid for object / relational mapping.


----
James Robinson
Socialserve.com


pgsql-general by date:

Previous
From: Bruno Wolff III
Date:
Subject: Re: client interfaces
Next
From: Tom Lane
Date:
Subject: Re: Composite type versus Domain constraints.