Обсуждение: Function with defval returns error
Hi All,<br /><br />Following test returns error on 8.4 cvs head. it looks like an issue<br /><br clear="all" />Testcase:(8.4 CVS head)<br />====================<br /> CREATE OR REPLACE FUNCTION f007( a INTEGER, <br /> b INTEGER DEFAULT 10 ) RETURNS INTEGER <br /> AS $$ <br /> select 10; <br /> $$ language sql; <br/><br /> CREATE OR REPLACE FUNCTION f007( a INTEGER DEFAULT 10, <br /> b INTEGER DEFAULT 10, <br /> c INTEGER DEFAULT 10) RETURNS INTEGER <br /> AS $$ <br /> select 10; <br /> $$ language sql; <br /><br/> CREATE OR REPLACE FUNCTION f007( a TIMESTAMP DEFAULT to_date('01-JUN-06 14:03:50', 'DD-MON-YY HH24:MI:SS') ) RETURNSTIMESTAMP <br /> AS $$ <br /> select current_date::timestamp; <br /> $$ language sql; <br /><br />postgres=#SELECT f007( to_date('01-JUN-06 14:03:50', 'DD-MON-YY HH24:MI:SS') ); <br />ERROR: functions with parameterdefaults f007(integer, integer, integer) and f007(integer, integer) are ambiguous <br /><br /><br />I think thisshould not return error as the input args here is timestamp... inputs?<br /><br />Thanks,<br />Rushabh Lathia<br /><ahref="http://www.EnterpriseDB.com">www.EnterpriseDB.com</a>
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 DEFAULT 10, > c INTEGER DEFAULT 10) RETURNS INTEGER > AS $$ > select 10; > $$ language sql; > > CREATE OR REPLACE FUNCTION f007( a TIMESTAMP DEFAULT > to_date('01-JUN-06 14:03:50', 'DD-MON-YY HH24:MI:SS') ) RETURNS TIMESTAMP > AS $$ > select current_date::timestamp; > $$ language sql; > > postgres=# SELECT f007( to_date('01-JUN-06 14:03:50', 'DD-MON-YY > HH24:MI:SS') ); > ERROR: functions with parameter defaults f007(integer, integer, > integer) and f007(integer, integer) are ambiguous > > > 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. When it considers a function based on available default values, it does not consider argument types. So if there is another function with the same number of arguments, it bails out. Feel free to propose improvements.
Hello 2008/12/15 Rushabh Lathia <rushabh.lathia@gmail.com>: > 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 FUNCTION f007( a INTEGER DEFAULT 10, > b INTEGER DEFAULT 10, > c INTEGER DEFAULT 10) RETURNS INTEGER > AS $$ > select 10; > $$ language sql; > > CREATE OR REPLACE FUNCTION f007( a TIMESTAMP DEFAULT to_date('01-JUN-06 > 14:03:50', 'DD-MON-YY HH24:MI:SS') ) RETURNS TIMESTAMP > AS $$ > select current_date::timestamp; > $$ language sql; > > postgres=# SELECT f007( to_date('01-JUN-06 14:03:50', 'DD-MON-YY > HH24:MI:SS') ); > ERROR: functions with parameter defaults f007(integer, integer, integer) > and f007(integer, integer) are ambiguous > > > I think this should not return error as the input args here is timestamp... > inputs? > you are right - this is known problem - because postgresql identify ambigonous calling and choise the best function in two places - simply we identify ambigonous call to early (algoritm is more fast then smart) - so ugly efect is identifivation of stored ambiguous functions when you call other function with same name. Pavel > Thanks, > Rushabh Lathia > www.EnterpriseDB.com
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. regards, tom lane
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.
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:
There is that one case where a call that could be allowed is overly-cautiouslyOn 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.
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
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 >
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
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. 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 >
On Tue, Dec 16, 2008 at 5:35 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
Raise exception when find similar function, do you mean similar function with different pathpos ? Or similar function with defval ?
> When we find the (pathpos < prevResult->pathpos) intopersonally I prefer raise exception, when I find similar function, we
> 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.
>
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.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
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 >
"Pavel Stehule" <pavel.stehule@gmail.com> 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 generate an ambiguous-function error on the fly when the currently seen contents of pg_proc create an ambiguous situation. In which connection, there's yet another thing I don't like about the current patch behavior. Given create function foo (f1 int, f2 int = 42)create function foo (f1 int, f2 numeric = 42.0) select foo(10) I accept that there's nothing much we can do except throw an "ambiguous function" error. However, the patch also throws error for create function foo (f1 int, f2 int = 42)create function foo (f1 int, f2 int = 42, f2 int = 43) select foo(10) It seems to me that we could usefully consider that the function with fewer defaulted arguments takes precedence. In particular, the limiting case of that is that a function with no defaulted arguments takes precedence over those with some. 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. regards, tom lane
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 rejects this case: #include <iostream> using namespace std; int foo(int f1) { return 1; } int foo(int f1, int f2 = 42) { return 2; } int foo(int f1, int f2 = 42, int f3 = 43) { return 3; } int main() { cout << foo(10) << endl; } test.cpp: In function 'int main()': test.cpp:9: error: call of overloaded 'foo(int)' is ambiguous test.cpp:4: note: candidates are: int foo(int) test.cpp:5: note: int foo(int, int) test.cpp:6: note: int foo(int, int, int) Interestingly, it complains about the calls, not the declarations, which is what I might have argued against. So, I'd rather reject the foo(10) call. The least-defaults rule doesn't strike me as very appealing. If you are porting Oracle functions with 40 arguments, it's very confusing and error-prone to say that the 35-defaults variant will be called over the 37-default variant, more so if you extend this to name-based parameter lists where parameters and defaults can be in any order. The whole thing is probably a mistake and should be rejected.
Peter Eisentraut <peter_e@gmx.net> 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 > strike me as very appealing. OK, I think we're in agreement on this. I'll make it happen. regards, tom lane
"Rushabh Lathia" <rushabh.lathia@gmail.com> 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 INTEGER DEFAULT 10) RETURNS INTEGER > AS $$ > select 10; > $$ language sql; > CREATE OR REPLACE FUNCTION f007( a TIMESTAMP DEFAULT to_date('01-JUN-06 > 14:03:50', 'DD-MON-YY HH24:MI:SS') ) RETURNS TIMESTAMP > AS $$ > select current_date::timestamp; > $$ language sql; > postgres=# SELECT f007( to_date('01-JUN-06 14:03:50', 'DD-MON-YY > HH24:MI:SS') ); > ERROR: functions with parameter defaults f007(integer, integer, integer) > and f007(integer, integer) are ambiguous > I think this should not return error as the input args here is timestamp... 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
"Rushabh Lathia" <rushabh.lathia@gmail.com> 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
> > 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 > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
On Thu, Dec 18, 2008 at 11:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I did fast test and now it seems great. Thanks.
Regards,
Rushabh Lathia"Rushabh Lathia" <rushabh.lathia@gmail.com> writes:> Another issue found on CVS head ....> ...> postgres=> select f_test(10);I had some difficulty reproducing this locally. Would you check it's
> ERROR: cache lookup failed for type 2139062142
fixed by latest commit?
I did fast test and now it seems great. Thanks.
Regards,
www.Enterprisedb.com