On Thu, Dec 18, 2008 at 11:54 PM, Tom Lane wrote:
> "Rushabh Lathia" writes:
> > Another issue found on CVS head
> > ...
> > postgres=> select f_test(10);
> > ERROR: cache lookup failed for type 2139062142
>
> I had some difficulty reproducing this locally. Would you check it's
> fixed by
>
> This is fixed in my recent commit --- the ambiguous-function error won't
> occur unless the ambiguous functions represent the best match to the
> actual arguments.
>
>regards, tom lane
>
I did some fast test, and now, it is well, so thank you
regards
Pavel Stehule
> -
"Rushabh Lathia" writes:
> Another issue found on CVS head
> ...
> postgres=> select f_test(10);
> ERROR: cache lookup failed for type 2139062142
I had some difficulty reproducing this locally. Would you check it's
fixed by latest commit?
regards, tom lane
--
Sen
"Rushabh Lathia" writes:
>CREATE OR REPLACE FUNCTION f007( a INTEGER,
> b INTEGER DEFAULT 10 ) RETURNS INTEGER
>AS $$
>select 10;
>$$ language sql;
>CREATE OR REPLACE FUNCTION f007( a INTEGER DEFAULT 10,
> b INTEGER DEFAULT 10,
> c INTEG
Peter Eisentraut writes:
> Tom Lane wrote:
>> This case *must* work:
>>
>> create function foo (f1 int)
>> create function foo (f1 int, f2 int = 42)
>>
>> select foo(10)
> I tried out C++, and it rejects this case:
> ...
> So, I'd rather reject the foo(10) call. The least-defaults rule doesn't
Tom Lane wrote:
This case *must* work:
create function foo (f1 int)
create function foo (f1 int, f2 int = 42)
select foo(10)
and it seems like just an arbitrary exception if you don't have a rule
about preferring fewer defaults over more.
I tried out C++, and it rejec
"Pavel Stehule" writes:
> I'll write patch that block creating all ambiguous overloading.
Don't bother --- it's a useless solution because you can't guarantee
that concurrent insertions into pg_proc won't create an ambiguous
situation. You have to define the resolution rules to cope, or else
gen
2008/12/16 Rushabh Lathia :
>
>
> On Tue, Dec 16, 2008 at 5:35 PM, Pavel Stehule
> wrote:
>>
>> 2008/12/16 Rushabh Lathia :
>> >
>> > When we find the (pathpos < prevResult->pathpos) into
>> > FuncnameGetCandidates(), we just replacing the prevResult with the
>> > newResult.
>> >
>> > While replac
On Tue, Dec 16, 2008 at 5:35 PM, Pavel Stehule wrote:
> 2008/12/16 Rushabh Lathia :
> >
> > 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 th
2008/12/16 Rushabh Lathia :
>
> 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 arg
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
Hello
I'll write patch that block creating all ambiguous overloading.
Regards
Pavel Stehule
2008/12/16 Rushabh Lathia :
>
> 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) RETU
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 REPLA
On Monday 15 December 2008 15:43:00 Tom Lane wrote:
> Peter Eisentraut 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
Peter Eisentraut 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 polymor
Hello
2008/12/15 Rushabh Lathia :
> Hi All,
>
> Following test returns error on 8.4 cvs head. it looks like an issue
>
> Testcase: (8.4 CVS head)
>
>CREATE OR REPLACE FUNCTION f007( a INTEGER,
> b INTEGER DEFAULT 10 ) RETURNS INTEGER
>AS $$
>select
Rushabh Lathia wrote:
Testcase: (8.4 CVS head)
CREATE OR REPLACE FUNCTION f007( a INTEGER,
b INTEGER DEFAULT 10 ) RETURNS INTEGER
AS $$
select 10;
$$ language sql;
CREATE OR REPLACE FUNCTION f007( a INTEGER DEFAULT 10,
b INTEGER DEF
Hi All,
Following test returns error on 8.4 cvs head. it looks like an issue
Testcase: (8.4 CVS head)
CREATE OR REPLACE FUNCTION f007( a INTEGER,
b INTEGER DEFAULT 10 ) RETURNS INTEGER
AS $$
select 10;
$$ language sql;
CREATE OR REPLACE FUNCTI
18 matches
Mail list logo