Re: Function with defval returns error

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
>