Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Admittedly, we have trouble resolving the type to use when a function is
>> overloaded with both a domain and a base type, but that's hardly
>> surprising.
> Even if you try to work it out, it's going to be a mess. During
> resolution, you would have to look inside the data to figure out which
> domain, if any, it might fit into.
No, we'd just use the declared type of the input to determine what to
do, same as we do now. If you want a domain-specific function to be
applied, you need to have the input be already of that domain, or you
coerce to it.
> If you insist on allowing domains in argument lists, then I think the best
> approach is this: For purpose of function resolution, types and all
> domains defined over them are equivalent. That would mean, for example,
> that if you define positive_int as domain over int, then you cannot define
> foofunc(int) and foofunc(positive_int) as the same time.
I think that'd be throwing the baby out with the bathwater. The above
is, more or less, *exactly* what you want to do in typical scenarios.
foofunc(int) is the general case, foofunc(positive_int) offers some sort
of performance or other advantage for the special case.
We do have some usable functionality in this area today:
regression=# create domain positive_int as int check (value > 0);
CREATE DOMAIN
regression=# create function foofunc(int) returns int as 'select 1' language sql;
CREATE FUNCTION
regression=# create function foofunc(positive_int) returns int as 'select 2' language
sql;
CREATE FUNCTION
regression=# select foofunc(1);
foofunc
---------
1
(1 row)
regression=# select foofunc(1::positive_int);
foofunc
---------
2
(1 row)
regression=#
Prohibiting this setup would take away usable if limited functionality,
in return for what? The fact that "foofunc(1::int2)" doesn't work
without an explicit cast is annoying, but it's not significantly
different in my mind from the fact that "to_hex(1::int2)" doesn't work.
We're not going to forbid users from supplying both int4 and int8
versions of a function, so we shouldn't forbid base and domain versions
either.
I think we could make most of the problems you cite go away if, at the
top of func_select_candidate() where we chop input types to base types,
we also discard any candidates that take domain types. They're
guaranteed not to match at that point, so we aren't losing any cases
that work. The overhead of doing this is a tad annoying, but maybe we
can combine it with some other catalog lookup.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
