Re: Function with defval returns error

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