Thread: Domains and function arguments
It seems that there are still a few problems with the resolution of functions that have domains as arguments. Take these two domains: create domain testdomain1 as int; create domain testdomain2 as int; Take these two functions: create function foofunc(testdomain1) returns int as 'select 1' language sql; create function foofunc(testdomain2) returns int as 'select 2' language sql; Calling foofunc(1) fails with the usual error message. Take these two functions: create function foofunc(testdomain1) returns int as 'select 1' language sql; create function foofunc(int) returns int as 'select 2' language sql; Calling foofunc(1) calls the second function. This is wrong, because int and testdomain2 are equivalent types, so the behavior should be identical to the above. Take these two functions: create function foofunc(testdomain1) returns int as 'select 1' language sql; create function foofunc(bigint) returns int as 'select 2' language sql; Calling foofunc(1) fails with the usual error message. This is wrong, because testdomain1 is equivalent to int, and had we written foofunc(int), that's the one that would have been called, in preference to foofunc(bigint). The SQL standard does not allow functions to have domains as arguments. Semantically, they have a point. Domains are not distinct types from their base types, just different ranges within those types, and the choice of function should just depend on the nature of the data, not in which range it was declared to fall. I think we should consider following the standard. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> The SQL standard does not allow functions to have domains as arguments.
> Semantically, they have a point.
I don't think they do. Declaring a domain as the input type seems a
very natural way of asserting that the function only works over a subset
of the base input type. For example, log() might usefully be declared
to take arguments from a "positivereal" domain.
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.
The present algorithm for ambiguous-function resolution is probably
excessively unfriendly to functions with domain inputs: it will match
them *only* when they are an exact match (ie, the input argument is
already declared or coerced to the domain type). I think that's bowing
quite far enough in the direction of the standard; I'd like to loosen
it someday, but don't have time to think about it more right now.
regards, tom lane
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. That means that the resolution of an expression depends on the actual data, not just the structure of the data (i.e., the data type). Of course, an expression typically needs to be resolved before the data is plugged in, so this approach cannot work. 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. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> 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
Tom, "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." As a heavy PL/pgSQL function user, the above sounds completely reasonable & workable to me. -- Josh Berkus Aglio Database Solutions San Francisco