From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, pgsql-bugs(at)postgresql(dot)org, postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] BUG #4516: FOUND variable does not work after RETURN QUERY |
Date: | 2009-01-09 22:54:54 |
Message-ID: | 200901092254.n09MssY25608@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Uh, is this ready to be applied?
---------------------------------------------------------------------------
Pavel Stehule wrote:
> I am sending patch, that adds FOUND and GET DIAGNOSTICS support for
> RETURN QUERY statement
>
> Regards
> Pavel Stehule
>
>
>
> 2008/11/10 Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>:
> >>>>>> "Pavel" == "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
> >
> > >> Well, changing the semantics of an already-released statement
> > >> carries a risk of breaking existing apps that aren't expecting it
> > >> to change FOUND. So I'd want to see a pretty strong case why this
> > >> is important --- not just that it didn't meet someone's
> > >> didn't-read-the-manual expectation.
> >
> > Pavel> It's should do some problems, but I belive much less than
> > Pavel> change of casting or tsearch2 integration. And actually it's
> > Pavel> not ortogonal. Every not dynamic statement change FOUND
> > Pavel> variable.
> >
> > Regardless of what you think of FOUND, a more serious problem is this:
> >
> > postgres=# create function test(n integer) returns setof integer language plpgsql
> > as $f$
> > declare
> > rc bigint;
> > begin
> > return query (select i from generate_series(1,n) i);
> > get diagnostics rc = row_count;
> > raise notice 'rc = %',rc;
> > end;
> > $f$;
> > CREATE FUNCTION
> > postgres=# select test(3);
> > NOTICE: rc = 0
> > test
> > ------
> > 1
> > 2
> > 3
> > (3 rows)
> >
> > Since GET DIAGNOSTICS is documented as working for every SQL query
> > executed in the function, rather than for a specific list of
> > constructs, this is clearly a bug.
> >
> > --
> > Andrew (irc:RhodiumToad)
> >
> > --
> > Sent via pgsql-bugs mailing list (pgsql-bugs(at)postgresql(dot)org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-bugs
> >
[ Attachment, skipping... ]
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-01-09 23:03:35 | Re: [HACKERS] BUG #4516: FOUND variable does not work after RETURN QUERY |
Previous Message | David Slayter | 2009-01-09 19:57:39 | BUG #4608: postgresql.conf and other .conf not created |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-01-09 23:03:35 | Re: [HACKERS] BUG #4516: FOUND variable does not work after RETURN QUERY |
Previous Message | Bruce Momjian | 2009-01-09 22:53:11 | Re: 2 small patches that fix 8.3.5 compile issues on Vista+MingW+Msys |