Обсуждение: 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