[ probably time to move this thread to -hackers ]
There is some moderately interesting reading material in section
4.17.4 "Domain constraints" of SQL:2008. In particular, it appears to
me that the standard goes out of its way to NOT claim that every value
that "is of" a domain type satisfies the domain's constraints. It looks
to me that the implementation they have in mind is that domain
constraints are to be checked:
(1) when a value is assigned to a *table* column having that domain type;
(2) when a value is converted to that domain type by an *explicit*
cast construct;
(3) nowhere else.
If I'm reading this right, it sidesteps most of the concerns we have
been worrying about here, at the cost of being perhaps more surprising
and less useful than one would expect. It would also mean that a lot
of our existing domain behavior is wrong. I think there is ammunition
here for an argument that, in effect, values "in flight" in expression
or query evaluation should always be considered to be of base types,
and domain constraints should only be checked when assigning to a
persistent storage location such as a table field or plpgsql variable
(plus the special case for CAST constructs).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
