Re: Function with defval returns error

Hi All,

Following test returns error on 8.4 cvs head. it looks like an issue

Testcase: (8.4 CVS head)
====================
CREATE OR REPLACE FUNCTION f007( a INTEGER,
b INTEGER DEFAULT 10 ) RETURNS INTEGER
AS $$
select 10;
$$ language sql;

CREATE OR REPLACE FUNCTION f007( a INTEGER DEFAULT 10,
b INTEGER DEFAULT 10,
c INTEGER DEFAULT 10) RETURNS INTEGER
AS $$
select 10;
$$ language sql;

CREATE OR REPLACE FUNCTION f007( a TIMESTAMP DEFAULT to_date('01-JUN-06
14:03:50', 'DD-MON-YY HH24:MI:SS') ) RETURNS TIMESTAMP
AS $$
select current_date::timestamp;
$$ language sql;

postgres=# SELECT f007( to_date('01-JUN-06 14:03:50', 'DD-MON-YY
HH24:MI:SS') );
ERROR: functions with parameter defaults f007(integer, integer, integer)
and f007(integer, integer) are ambiguous

I think this should not return error as the input args here is timestamp...
inputs?

Thanks,
Rushabh Lathia
www.EnterpriseDB.com

Rushabh Lathia wrote:
> Testcase: (8.4 CVS head)
> ====================
> CREATE OR REPLACE FUNCTION f007( a INTEGER,
> b INTEGER DEFAULT 10 ) RETURNS INTEGER
> AS $$
> select 10;
> $$ language sql;
>
> CREATE OR REPLACE FUNCTION f007( a INTEGER DEFAULT 10,
> b INTEGER DEFAULT 10,
> c INTEGER DEFAULT 10) RETURNS INTEGER
> AS $$
> select 10;
> $$ language sql;
>
> CREATE OR REPLACE FUNCTION f007( a TIMESTAMP DEFAULT
> to_date('01-JUN-06 14:03:50', 'DD-MON-YY HH24:MI:SS') ) RETURNS TIMESTAMP
> AS $$
> select current_date::timestamp;
> $$ language sql;
>
> postgres=# SELECT f007( to_date('01-JUN-06 14:03:50', 'DD-MON-YY
> HH24:MI:SS') );
> ERROR: functions with parameter defaults f007(integer, integer,
> integer) and f007(integer, integer) are ambiguous
>
>
> I think this should not return error as the input args here is
> timestamp... inputs?

In theory yes, but it's currently not that smart. When it considers a
function based on available default values, it does not consider
argument types. So if there is another function with the same number of
arguments, it bails out.

Feel free to propose improvements.

Hello

2008/12/15 Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>:
> Hi All,
>
> Following test returns error on 8.4 cvs head. it looks like an issue
>
> Testcase: (8.4 CVS head)
> ====================
> CREATE OR REPLACE FUNCTION f007( a INTEGER,
> b INTEGER DEFAULT 10 ) RETURNS INTEGER
> AS $$
> select 10;
> $$ language sql;
>
> CREATE OR REPLACE FUNCTION f007( a INTEGER DEFAULT 10,
> b INTEGER DEFAULT 10,
> c INTEGER DEFAULT 10) RETURNS INTEGER
> AS $$
> select 10;
> $$ language sql;
>
> CREATE OR REPLACE FUNCTION f007( a TIMESTAMP DEFAULT to_date('01-JUN-06
> 14:03:50', 'DD-MON-YY HH24:MI:SS') ) RETURNS TIMESTAMP
> AS $$
> select current_date::timestamp;
> $$ language sql;
>
> postgres=# SELECT f007( to_date('01-JUN-06 14:03:50', 'DD-MON-YY
> HH24:MI:SS') );
> ERROR: functions with parameter defaults f007(integer, integer, integer)
> and f007(integer, integer) are ambiguous
>
>
> I think this should not return error as the input args here is timestamp...
> inputs?
>

you are right - this is known problem - because postgresql identify
ambigonous calling and choise the best function in two places - simply
we identify ambigonous call to early (algoritm is more fast then
smart) - so ugly efect is identifivation of stored ambiguous functions
when you call other function with same name.

Pavel

> Thanks,
> Rushabh Lathia
> www.EnterpriseDB.com

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Rushabh Lathia wrote:
>> I think this should not return error as the input args here is
>> timestamp... inputs?

> In theory yes, but it's currently not that smart.

This is truly horrid. Was that patch *really* ready to commit?
I noticed some comments added to polymorphism.sql that certainly
look like there's still a lot of half-bakedness in it.

regards, tom lane

On Monday 15 December 2008 15:43:00 Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Rushabh Lathia wrote:
> >> I think this should not return error as the input args here is
> >> timestamp... inputs?
> >
> > In theory yes, but it's currently not that smart.
>
> This is truly horrid. Was that patch *really* ready to commit?
> I noticed some comments added to polymorphism.sql that certainly
> look like there's still a lot of half-bakedness in it.

There is that one case where a call that could be allowed is overly-cautiously
rejected. That only happens if you have a mix of overloading and default
parameters. It's not really half-baked in the sense that it is not
digestible; it's just not the greatest cake yet. It's
improvement-compatible.

Another issue found on CVS head ....

CREATE USER test WITH PASSWORD 'test';
CREATE SCHEMA AUTHORIZATION test;

CREATE OR REPLACE FUNCTION f_test(x in numeric) RETURNS numeric as $$
BEGIN
RETURN x;
END;
$$ language plpgsql;

select f_test(10);

\c postgres test;

select f_test(10);

CREATE OR REPLACE FUNCTION f_test(x in numeric, y in varchar default 'Local
Function with parameters') RETURNs numeric as $$
BEGIN
RETURN x+1;
END;
$$ language plpgsql;

postgres=> select f_test(10);
ERROR: cache lookup failed for type 2139062142

On Tue, Dec 16, 2008 at 2:07 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:

> On Monday 15 December 2008 15:43:00 Tom Lane wrote:
> > Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > > Rushabh Lathia wrote:
> > >> I think this should not return error as the input args here is
> > >> timestamp... inputs?
> > >
> > > In theory yes, but it's currently not that smart.
> >
> > This is truly horrid. Was that patch *really* ready to commit?
> > I noticed some comments added to polymorphism.sql that certainly
> > look like there's still a lot of half-bakedness in it.
>
> There is that one case where a call that could be allowed is
> overly-cautiously
> rejected. That only happens if you have a mix of overloading and default
> parameters. It's not really half-baked in the sense that it is not
> digestible; it's just not the greatest cake yet. It's
> improvement-compatible.
>

--
Rushabh Lathia

Hello

I'll write patch that block creating all ambiguous overloading.

Regards
Pavel Stehule

2008/12/16 Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>:
>
> Another issue found on CVS head ....
>
> CREATE USER test WITH PASSWORD 'test';
> CREATE SCHEMA AUTHORIZATION test;
>
> CREATE OR REPLACE FUNCTION f_test(x in numeric) RETURNS numeric as $$
> BEGIN
> RETURN x;
> END;
> $$ language plpgsql;
>
> select f_test(10);
>
> \c postgres test;
>
> select f_test(10);
>
> CREATE OR REPLACE FUNCTION f_test(x in numeric, y in varchar default 'Local
> Function with parameters') RETURNs numeric as $$
> BEGIN
> RETURN x+1;
> END;
> $$ language plpgsql;
>
> postgres=> select f_test(10);
> ERROR: cache lookup failed for type 2139062142
>
>
>
>
> On Tue, Dec 16, 2008 at 2:07 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>>
>> On Monday 15 December 2008 15:43:00 Tom Lane wrote:
>> > Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> > > Rushabh Lathia wrote:
>> > >> I think this should not return error as the input args here is
>> > >> timestamp... inputs?
>> > >
>> > > In theory yes, but it's currently not that smart.
>> >
>> > This is truly horrid. Was that patch *really* ready to commit?
>> > I noticed some comments added to polymorphism.sql that certainly
>> > look like there's still a lot of half-bakedness in it.
>>
>> There is that one case where a call that could be allowed is
>> overly-cautiously
>> rejected. That only happens if you have a mix of overloading and default
>> parameters. It's not really half-baked in the sense that it is not
>> digestible; it's just not the greatest cake yet. It's
>> improvement-compatible.
>
>
>
> --
> Rushabh Lathia
>

When we find the (pathpos < prevResult->pathpos) into
FuncnameGetCandidates(), we just replacing the prevResult with the
newResult.

While replacing the previous with new we do not replace the args. I think in
case of default we need to take care for the args as well.

Thanks,
Rushabh

On Tue, Dec 16, 2008 at 12:26 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>wrote:

> Hello
>
> I'll write patch that block creating all ambiguous overloading.
>
> Regards
> Pavel Stehule
>
> 2008/12/16 Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>:
> >
> > Another issue found on CVS head ....
> >
> > CREATE USER test WITH PASSWORD 'test';
> > CREATE SCHEMA AUTHORIZATION test;
> >
> > CREATE OR REPLACE FUNCTION f_test(x in numeric) RETURNS numeric as $$
> > BEGIN
> > RETURN x;
> > END;
> > $$ language plpgsql;
> >
> > select f_test(10);
> >
> > \c postgres test;
> >
> > select f_test(10);
> >
> > CREATE OR REPLACE FUNCTION f_test(x in numeric, y in varchar default
> 'Local
> > Function with parameters') RETURNs numeric as $$
> > BEGIN
> > RETURN x+1;
> > END;
> > $$ language plpgsql;
> >
> > postgres=> select f_test(10);
> > ERROR: cache lookup failed for type 2139062142
> >
> >
> >
> >
> > On Tue, Dec 16, 2008 at 2:07 AM, Peter Eisentraut <peter_e(at)gmx(dot)net>
> wrote:
> >>
> >> On Monday 15 December 2008 15:43:00 Tom Lane wrote:
> >> > Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> >> > > Rushabh Lathia wrote:
> >> > >> I think this should not return error as the input args here is
> >> > >> timestamp... inputs?
> >> > >
> >> > > In theory yes, but it's currently not that smart.
> >> >
> >> > This is truly horrid. Was that patch *really* ready to commit?
> >> > I noticed some comments added to polymorphism.sql that certainly
> >> > look like there's still a lot of half-bakedness in it.
> >>
> >> There is that one case where a call that could be allowed is
> >> overly-cautiously
> >> rejected. That only happens if you have a mix of overloading and
> default
> >> parameters. It's not really half-baked in the sense that it is not
> >> digestible; it's just not the greatest cake yet. It's
> >> improvement-compatible.
> >
> >
> >
> > --
> > Rushabh Lathia
> >
>

--
Rushabh Lathia

2008/12/16 Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>:
>
> When we find the (pathpos < prevResult->pathpos) into
> FuncnameGetCandidates(), we just replacing the prevResult with the
> newResult.
>
> While replacing the previous with new we do not replace the args. I think in
> case of default we need to take care for the args as well.
>

personally I prefer raise exception, when I find similar function, we
don't need emulate Oracle behave.

Regards
Pavel Stehule

> Thanks,
> Rushabh
>
> On Tue, Dec 16, 2008 at 12:26 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>>
>> Hello
>>
>> I'll write patch that block creating all ambiguous overloading.
>>
>> Regards
>> Pavel Stehule
>>
>> 2008/12/16 Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>:
>> >
>> > Another issue found on CVS head ....
>> >
>> > CREATE USER test WITH PASSWORD 'test';
>> > CREATE SCHEMA AUTHORIZATION test;
>> >
>> > CREATE OR REPLACE FUNCTION f_test(x in numeric) RETURNS numeric as $$
>> > BEGIN
>> > RETURN x;
>> > END;
>> > $$ language plpgsql;
>> >
>> > select f_test(10);
>> >
>> > \c postgres test;
>> >
>> > select f_test(10);
>> >
>> > CREATE OR REPLACE FUNCTION f_test(x in numeric, y in varchar default
>> > 'Local
>> > Function with parameters') RETURNs numeric as $$
>> > BEGIN
>> > RETURN x+1;
>> > END;
>> > $$ language plpgsql;
>> >
>> > postgres=> select f_test(10);
>> > ERROR: cache lookup failed for type 2139062142
>> >
>> >
>> >
>> >
>> > On Tue, Dec 16, 2008 at 2:07 AM, Peter Eisentraut <peter_e(at)gmx(dot)net>
>> > wrote:
>> >>
>> >> On Monday 15 December 2008 15:43:00 Tom Lane wrote:
>> >> > Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> >> > > Rushabh Lathia wrote:
>> >> > >> I think this should not return error as the input args here is
>> >> > >> timestamp... inputs?
>> >> > >
>> >> > > In theory yes, but it's currently not that smart.
>> >> >
>> >> > This is truly horrid. Was that patch *really* ready to commit?
>> >> > I noticed some comments added to polymorphism.sql that certainly
>> >> > look like there's still a lot of half-bakedness in it.
>> >>
>> >> There is that one case where a call that could be allowed is
>> >> overly-cautiously
>> >> rejected. That only happens if you have a mix of overloading and
>> >> default
>> >> parameters. It's not really half-baked in the sense that it is not
>> >> digestible; it's just not the greatest cake yet. It's
>> >> improvement-compatible.
>> >
>> >
>> >
>> > --
>> > Rushabh Lathia
>> >
>
>
>
> --
> Rushabh Lathia
>

On Tue, Dec 16, 2008 at 5:35 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>wrote:

> 2008/12/16 Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>:
> >
> > When we find the (pathpos < prevResult->pathpos) into
> > FuncnameGetCandidates(), we just replacing the prevResult with the
> > newResult.
> >
> > While replacing the previous with new we do not replace the args. I think
> in
> > case of default we need to take care for the args as well.
> >
>
> personally I prefer raise exception, when I find similar function, we
> don't need emulate Oracle behave.

Raise exception when find similar function, do you mean similar function
with different pathpos ? Or similar function with defval ?

>
> Regards
> Pavel Stehule
>
> > Thanks,
> > Rushabh
> >
> > On Tue, Dec 16, 2008 at 12:26 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com
> >
> > wrote:
> >>
> >> Hello
> >>
> >> I'll write patch that block creating all ambiguous overloading.
> >>
> >> Regards
> >> Pavel Stehule
> >>
> >> 2008/12/16 Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>:
> >> >
> >> > Another issue found on CVS head ....
> >> >
> >> > CREATE USER test WITH PASSWORD 'test';
> >> > CREATE SCHEMA AUTHORIZATION test;
> >> >
> >> > CREATE OR REPLACE FUNCTION f_test(x in numeric) RETURNS numeric as $$
> >> > BEGIN
> >> > RETURN x;
> >> > END;
> >> > $$ language plpgsql;
> >> >
> >> > select f_test(10);
> >> >
> >> > \c postgres test;
> >> >
> >> > select f_test(10);
> >> >
> >> > CREATE OR REPLACE FUNCTION f_test(x in numeric, y in varchar default
> >> > 'Local
> >> > Function with parameters') RETURNs numeric as $$
> >> > BEGIN
> >> > RETURN x+1;
> >> > END;
> >> > $$ language plpgsql;
> >> >
> >> > postgres=> select f_test(10);
> >> > ERROR: cache lookup failed for type 2139062142
> >> >
> >> >
> >> >
> >> >
> >> > On Tue, Dec 16, 2008 at 2:07 AM, Peter Eisentraut <peter_e(at)gmx(dot)net>
> >> > wrote:
> >> >>
> >> >> On Monday 15 December 2008 15:43:00 Tom Lane wrote:
> >> >> > Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> >> >> > > Rushabh Lathia wrote:
> >> >> > >> I think this should not return error as the input args here is
> >> >> > >> timestamp... inputs?
> >> >> > >
> >> >> > > In theory yes, but it's currently not that smart.
> >> >> >
> >> >> > This is truly horrid. Was that patch *really* ready to commit?
> >> >> > I noticed some comments added to polymorphism.sql that certainly
> >> >> > look like there's still a lot of half-bakedness in it.
> >> >>
> >> >> There is that one case where a call that could be allowed is
> >> >> overly-cautiously
> >> >> rejected. That only happens if you have a mix of overloading and
> >> >> default
> >> >> parameters. It's not really half-baked in the sense that it is not
> >> >> digestible; it's just not the greatest cake yet. It's
> >> >> improvement-compatible.
> >> >
> >> >
> >> >
> >> > --
> >> > Rushabh Lathia
> >> >
> >
> >
> >
> > --
> > Rushabh Lathia
> >
>

--
Rushabh Lathia

2008/12/16 Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>:
>
>
> On Tue, Dec 16, 2008 at 5:35 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>>
>> 2008/12/16 Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>:
>> >
>> > When we find the (pathpos < prevResult->pathpos) into
>> > FuncnameGetCandidates(), we just replacing the prevResult with the
>> > newResult.
>> >
>> > While replacing the previous with new we do not replace the args. I
>> > think in
>> > case of default we need to take care for the args as well.
>> >
>>
>> personally I prefer raise exception, when I find similar function, we
>> don't need emulate Oracle behave.
>
> Raise exception when find similar function, do you mean similar function
> with different pathpos ? Or similar function with defval ?

I mean similar with defval

Pavel

>
>>
>>
>> Regards
>> Pavel Stehule
>>
>> > Thanks,
>> > Rushabh
>> >
>> > On Tue, Dec 16, 2008 at 12:26 PM, Pavel Stehule
>> > <pavel(dot)stehule(at)gmail(dot)com>
>> > wrote:
>> >>
>> >> Hello
>> >>
>> >> I'll write patch that block creating all ambiguous overloading.
>> >>
>> >> Regards
>> >> Pavel Stehule
>> >>
>> >> 2008/12/16 Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>:
>> >> >
>> >> > Another issue found on CVS head ....
>> >> >
>> >> > CREATE USER test WITH PASSWORD 'test';
>> >> > CREATE SCHEMA AUTHORIZATION test;
>> >> >
>> >> > CREATE OR REPLACE FUNCTION f_test(x in numeric) RETURNS numeric as $$
>> >> > BEGIN
>> >> > RETURN x;
>> >> > END;
>> >> > $$ language plpgsql;
>> >> >
>> >> > select f_test(10);
>> >> >
>> >> > \c postgres test;
>> >> >
>> >> > select f_test(10);
>> >> >
>> >> > CREATE OR REPLACE FUNCTION f_test(x in numeric, y in varchar default
>> >> > 'Local
>> >> > Function with parameters') RETURNs numeric as $$
>> >> > BEGIN
>> >> > RETURN x+1;
>> >> > END;
>> >> > $$ language plpgsql;
>> >> >
>> >> > postgres=> select f_test(10);
>> >> > ERROR: cache lookup failed for type 2139062142
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Dec 16, 2008 at 2:07 AM, Peter Eisentraut <peter_e(at)gmx(dot)net>
>> >> > wrote:
>> >> >>
>> >> >> On Monday 15 December 2008 15:43:00 Tom Lane wrote:
>> >> >> > Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> >> >> > > Rushabh Lathia wrote:
>> >> >> > >> I think this should not return error as the input args here is
>> >> >> > >> timestamp... inputs?
>> >> >> > >
>> >> >> > > In theory yes, but it's currently not that smart.
>> >> >> >
>> >> >> > This is truly horrid. Was that patch *really* ready to commit?
>> >> >> > I noticed some comments added to polymorphism.sql that certainly
>> >> >> > look like there's still a lot of half-bakedness in it.
>> >> >>
>> >> >> There is that one case where a call that could be allowed is
>> >> >> overly-cautiously
>> >> >> rejected. That only happens if you have a mix of overloading and
>> >> >> default
>> >> >> parameters. It's not really half-baked in the sense that it is not
>> >> >> digestible; it's just not the greatest cake yet. It's
>> >> >> improvement-compatible.
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Rushabh Lathia
>> >> >
>> >
>> >
>> >
>> > --
>> > Rushabh Lathia
>> >
>
>
>
> --
> Rushabh Lathia
>

"Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)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

Tom Lane wrote:
> 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.

I tried out C++, and it rejects this case:

#include <iostream>
using namespace std;

int foo(int f1) { return 1; }
int foo(int f1, int f2 = 42) { return 2; }
int foo(int f1, int f2 = 42, int f3 = 43) { return 3; }

int main() {
cout << foo(10) << endl;
}

test.cpp: In function 'int main()':
test.cpp:9: error: call of overloaded 'foo(int)' is ambiguous
test.cpp:4: note: candidates are: int foo(int)
test.cpp:5: note: int foo(int, int)
test.cpp:6: note: int foo(int, int, int)

Interestingly, it complains about the calls, not the declarations, which
is what I might have argued against.

So, I'd rather reject the foo(10) call. The least-defaults rule doesn't
strike me as very appealing. If you are porting Oracle functions with
40 arguments, it's very confusing and error-prone to say that the
35-defaults variant will be called over the 37-default variant, more so
if you extend this to name-based parameter lists where parameters and
defaults can be in any order. The whole thing is probably a mistake and
should be rejected.

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane wrote:
>> This case *must* work:
>>
>> create function foo (f1 int)
>> create function foo (f1 int, f2 int = 42)
>>
>> select foo(10)

> I tried out C++, and it rejects this case:
> ...
> So, I'd rather reject the foo(10) call. The least-defaults rule doesn't
> strike me as very appealing.

OK, I think we're in agreement on this. I'll make it happen.

regards, tom lane

"Rushabh Lathia" <rushabh(dot)lathia(at)gmail(dot)com> writes:
> CREATE OR REPLACE FUNCTION f007( a INTEGER,
> b INTEGER DEFAULT 10 ) RETURNS INTEGER
> AS $$
> select 10;
> $$ language sql;

> CREATE OR REPLACE FUNCTION f007( a INTEGER DEFAULT 10,
> b INTEGER DEFAULT 10,
> c INTEGER DEFAULT 10) RETURNS INTEGER
> AS $$
> select 10;
> $$ language sql;

> CREATE OR REPLACE FUNCTION f007( a TIMESTAMP DEFAULT to_date('01-JUN-06
> 14:03:50', 'DD-MON-YY HH24:MI:SS') ) RETURNS TIMESTAMP
> AS $$
> select current_date::timestamp;
> $$ language sql;

> postgres=# SELECT f007( to_date('01-JUN-06 14:03:50', 'DD-MON-YY
> HH24:MI:SS') );
> ERROR: functions with parameter defaults f007(integer, integer, integer)
> and f007(integer, integer) are ambiguous

> I think this should not return error as the input args here is timestamp...

This is fixed in my recent commit --- the ambiguous-function error won't
occur unless the ambiguous functions represent the best match to the
actual arguments.

regards, tom lane

"Rushabh Lathia" <rushabh(dot)lathia(at)gmail(dot)com> writes:
> Another issue found on CVS head ....
> ...
> postgres=> select f_test(10);
> ERROR: cache lookup failed for type 2139062142

I had some difficulty reproducing this locally. Would you check it's
fixed by latest commit?

regards, tom lane

>
> This is fixed in my recent commit --- the ambiguous-function error won't
> occur unless the ambiguous functions represent the best match to the
> actual arguments.
>
> regards, tom lane
>

I did some fast test, and now, it is well, so thank you

regards
Pavel Stehule

> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

On Thu, Dec 18, 2008 at 11:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Rushabh Lathia" <rushabh(dot)lathia(at)gmail(dot)com> writes:
> > Another issue found on CVS head ....
> > ...
> > postgres=> select f_test(10);
> > ERROR: cache lookup failed for type 2139062142
>
> I had some difficulty reproducing this locally. Would you check it's
> fixed by latest commit?

I did fast test and now it seems great. Thanks.

Regards,
Rushabh Lathia
www.Enterprisedb.com