Thomas Lockhart [EMAIL PROTECTED] writes:
We could treat exact and binary-compatible matches alike (doesn't seem
good), or put a special case into the operator selection rules to reduce
domains to their basetypes before making the exact match test.
There could also be an explicit heuristic
Tom Lane wrote:
If we take the hard SQL99 line that domains *are* the base type plus
constraints, then we could reduce domains to base types before we start
the entire matching process, and this issue would go away. This would
prevent declaring any specialized operators or functions for a
I wrote:
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.
Tom Lane wrote:
(...) or put a special case into the operator selection rules to reduce
domains to their basetypes before making the exact match test.
By definition,
which I believe should be read as
A domain is a set of permissible values (of a data type).
What I am trying to say is
Tom Lane wrote:
Any thoughts?
As we are talking about CAST,
if one CASTs to a domain, SQL99 says we have to check the constraints
and issue a integrity constraint violation if appropriate (6.22, GR 21).
--
Fernando Nasser
Red Hat - Toronto E-Mail: [EMAIL
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=#
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
