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 *after* the exact match
> gathering to look for an exact match for domains reduced to their base
> types. Is there any reason to look for domains before that?
The problem in the case I gave was that the "exact match" heuristic
was throwing away the operator we really wanted to use. I had
"domain + int4" where domain is really numeric. In the base case,
"numeric + int4", we'll keep both "numeric + numeric" and "int4 + int4"
since each has one exact match, and later decide that "numeric + numeric"
is preferred. In the domain case we will keep only "int4 + int4"
... oops. Testing later will not help.
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 domain.
(In fact, I'd be inclined to set things up so that it's impossible to
store domain type OIDs in pg_proc or pg_operator, thus saving the time
of doing getBaseType on one side of the match.) Thoughts?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
