[ 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