Re: Function with defval returns error

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
>