Re: Function with defval returns error
От | Pavel Stehule |
---|---|
Тема | Re: Function with defval returns error |
Дата | |
Msg-id | 162867790812160837k307b097ydbdd040e18ab9d5f@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Function with defval returns error ("Rushabh Lathia" <rushabh.lathia@gmail.com>) |
Список | pgsql-hackers |
2008/12/16 Rushabh Lathia <rushabh.lathia@gmail.com>: > > > On Tue, Dec 16, 2008 at 5:35 PM, Pavel Stehule <pavel.stehule@gmail.com> > wrote: >> >> 2008/12/16 Rushabh Lathia <rushabh.lathia@gmail.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.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 >> > > > > > -- > Rushabh Lathia >
В списке pgsql-hackers по дате отправления: