Re: Function with defval returns error

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
>