Re: Function with defval returns error

Поиск
Список
Период
Сортировка
От Rushabh Lathia
Тема Re: Function with defval returns error
Дата
Msg-id 460abcb10812152304y11dc1817n9a7b2b14bdc1a527@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Function with defval returns error  ("Pavel Stehule" <pavel.stehule@gmail.com>)
Ответы Re: Function with defval returns error  ("Pavel Stehule" <pavel.stehule@gmail.com>)
Список 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.stehule@gmail.com> wrote:
Hello

I'll write patch that block creating all ambiguous overloading.

Regards
Pavel Stehule

2008/12/16 Rushabh Lathia <rushabh.lathia@gmail.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@gmx.net> wrote:
>>
>> On Monday 15 December 2008 15:43:00 Tom Lane wrote:
>> > Peter Eisentraut <peter_e@gmx.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: ITAGAKI Takahiro
Дата:
Сообщение: Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1
Следующее
От: Emmanuel Cecchet
Дата:
Сообщение: Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1