"Pavel Stehule" <pavel.steh...@gmail.com> writes:
> I'll write patch that block creating all ambiguous overloading.
Don't bother --- it's a useless solution because you can't guarantee
that concurrent insertions into pg_proc won't create an ambiguous
situation. You have to define the resolution rules to cope, or else
generate an ambiguous-function error on the fly when the currently
seen contents of pg_proc create an ambiguous situation.
In which connection, there's yet another thing I don't like about
the current patch behavior. Given
create function foo (f1 int, f2 int = 42)
create function foo (f1 int, f2 numeric = 42.0)
select foo(10)
I accept that there's nothing much we can do except throw an "ambiguous
function" error. However, the patch also throws error for
create function foo (f1 int, f2 int = 42)
create function foo (f1 int, f2 int = 42, f2 int = 43)
select foo(10)
It seems to me that we could usefully consider that the function with
fewer defaulted arguments takes precedence. In particular, the limiting
case of that is that a function with no defaulted arguments takes
precedence over those with some. This case *must* work:
create function foo (f1 int)
create function foo (f1 int, f2 int = 42)
select foo(10)
and it seems like just an arbitrary exception if you don't have a rule
about preferring fewer defaults over more.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
