The DOMAIN patch is completely broken when it comes to type coercion
behavior. For one thing, it doesn't know that any operators or
functions on a domain's base type can be used with a domain:
domain=# create domain zip as char(2);
CREATE
domain=# create table foo (f1 zip);
CREATE
domain=# select f1 || 'z' from foo;
ERROR: Unable to identify an operator '||' for types 'zip' and 'unknown'
You will have to retype this query using an explicit cast
and casting does not help:
domain=# select f1::char(2) || 'z' from foo;
ERROR: Cannot cast type 'zip' to 'character'
There are more subtle problems too. Among other things, it will
generate expressions that are supposed to be labeled with the domain
type but are actually labeled with the domain's base type, leading to
all sorts of confusion. (The reason we had to introduce RelabelType
expression nodes a couple years ago was to avoid just this scenario.)
I am thinking that a non-broken approach would involve (1) treating
a domain as binary-compatible with its base type, and therefore with
all other domains on the same base type, and (2) allowing a coercion
function that produces the base type to be used to produce the domain
type. (The patch tries to do (2), but does it in the wrong places,
leading to the mislabeled-expression problem.)
An implication of this is that one could not define functions and
operators that implement any interesting domain-type-specific behavior.
This strikes me as okay --- it seems like domains are a shortcut to save
having to invent a real type, and so people wouldn't care about defining
domain-specific functions. If we don't accept binary equivalence of
domains to base types, then creating a useful domain will be nearly as
nontrivial as creating a new base type.
Comments?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
