Thread: polymorphic functions and domains

When I define two polymorpic functions, one taking
varchar and one bytea, there seems to be no confusion
choosing the varchar version when called with
the untyped literal 'abc'.

I really want two polymorphic functions, one taking
a domain data type using varchar and one bytea.
In that case, postgres complains that it cannot decide
which one to use when called with the
untyped literal 'abc'.

I thought I might could force the domain varchar version to be
chosen by casting the domain as varchar, but this does not
help.

The situation is explained in SQL below.

Can someone help me get qtest('abc') to use the qtest(astring)
function without having to explicitly cast 'abc'::astring;
I'm using 8.2.5 and Linux.k

Thanks,
TJ O'Donnell
www.gnova.com

----------------------------------------------
Drop Function ztest(Character Varying);
Drop Function ztest(bytea);

Drop Function qtest(astring);
Drop Function qtest(Bytea);
Drop Cast (astring as Character Varying);
Drop Domain astring;

Create Or Replace Function ztest(Character Varying) Returns Integer As 
$EOSQL$ Select length($1);
$EOSQL$ Language SQL;

Create Or Replace Function ztest(Bytea) Returns Integer As $EOSQL$ Select -(length($1));
$EOSQL$ Language SQL;

Select ztest('abc'::Character Varying);
-- worked as expected
Select ztest('abc'::Bytea);
-- worked as expected
Select ztest('abc');
-- worked as expected

Create Domain astring as Character Varying;

Create Or Replace Function qtest(astring) Returns Integer As $EOSQL$ Select length($1);
$EOSQL$ Language SQL;

Create Or Replace Function qtest(Bytea) Returns Integer As $EOSQL$ Select -(length($1));
$EOSQL$ Language SQL;

Select qtest('abc'::astring);
-- worked as expected
Select qtest('abc'::Bytea);
-- worked as expected

Select qtest('abc');
-- why did this not cause qtest(astring) to be chosen?

Create Cast (astring As Character Varying) Without Function As Implicit;
Select qtest('abc');
-- why did this not force qtest(astring) to be chosen?

"TJ O'Donnell" <tjo@acm.org> writes:
> I really want two polymorphic functions, one taking
> a domain data type using varchar and one bytea.

These aren't polymorphic functions, actually; they're just overloaded.

> In that case, postgres complains that it cannot decide
> which one to use when called with the
> untyped literal 'abc'.

Yeah, functions taking domains as arguments are problematic.  I believe
that with the current resolution rules, a function taking a domain can
only "win" an ambiguous-function comparison if it's an exact match
to the input types --- which in this case means you have to cast the
literal to the domain type.

There's been some talk of trying to rejigger the resolution rules to
make them more friendly to functions that're declared to take domains,
but no one's put forward any concrete proposal.  It's not at all clear
to me how to do it without introducing a lot of surprising behavior :-(
        regards, tom lane

I'm not sure I can propose a scheme that would
work in all situations, but one could simply
considered the built-in data type underlying
the domain.  In my case, this would mean deciding
between character varying and bytea, which seems to
work just fine.

As far as surprising behavior, isn't the scheme
for casting literals already prone to surprises?

TJ

Tom Lane wrote:
> "TJ O'Donnell" <tjo@acm.org> writes:
>> I really want two polymorphic functions, one taking
>> a domain data type using varchar and one bytea.
> 
> These aren't polymorphic functions, actually; they're just overloaded.
> 
>> In that case, postgres complains that it cannot decide
>> which one to use when called with the
>> untyped literal 'abc'.
> 
> Yeah, functions taking domains as arguments are problematic.  I believe
> that with the current resolution rules, a function taking a domain can
> only "win" an ambiguous-function comparison if it's an exact match
> to the input types --- which in this case means you have to cast the
> literal to the domain type.
> 
> There's been some talk of trying to rejigger the resolution rules to
> make them more friendly to functions that're declared to take domains,
> but no one's put forward any concrete proposal.  It's not at all clear
> to me how to do it without introducing a lot of surprising behavior :-(
> 
>             regards, tom lane