On Tue, Dec 16, 2008 at 5:35 PM, Pavel Stehule <pavel.steh...@gmail.com>wrote:
> 2008/12/16 Rushabh Lathia <rushabh.lat...@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 ? > > Regards > Pavel Stehule > > > Thanks, > > Rushabh > > > > On Tue, Dec 16, 2008 at 12:26 PM, Pavel Stehule <pavel.steh...@gmail.com > > > > wrote: > >> > >> Hello > >> > >> I'll write patch that block creating all ambiguous overloading. > >> > >> Regards > >> Pavel Stehule > >> > >> 2008/12/16 Rushabh Lathia <rushabh.lat...@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 <pete...@gmx.net> > >> > wrote: > >> >> > >> >> On Monday 15 December 2008 15:43:00 Tom Lane wrote: > >> >> > Peter Eisentraut <pete...@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
