Re: Function with defval returns error

From: "Rushabh Lathia" <rushabh(dot)lathia(at)gmail(dot)com>
To: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
Cc: "Peter Eisentraut" <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, rushabh(dot)lathia(at)enterprisedb(dot)com
Subject: Re: Function with defval returns error
Date: 2008-12-16 07:04:52
Message-ID: 460abcb10812152304y11dc1817n9a7b2b14bdc1a527@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Emmanuel Cecchet 2008-12-16 07:13:29 Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1
Previous Message ITAGAKI Takahiro 2008-12-16 07:02:17 Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1