Lists: | pgsql-bugspgsql-hackers |
---|
From: | "Michal szymanski" <szymanskim(at)datera(dot)pl> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | BUG #4516: FOUND variable does not work after RETURN QUERY |
Date: | 2008-11-06 16:38:12 |
Message-ID: | 200811061638.mA6GcCgp057944@wwwmaster.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
The following bug has been logged online:
Bug reference: 4516
Logged by: Michal szymanski
Email address: szymanskim(at)datera(dot)pl
PostgreSQL version: 8.3
Operating system: Windows
Description: FOUND variable does not work after RETURN QUERY
Details:
This short program display two rows instead one. If I use RETURN NEXT it
works.
CREATE TABLE test_table (
value VARCHAR
);
INSERT INTO test_table VALUES ('a');
INSERT INTO test_table VALUES ('b');
CREATE OR REPLACE FUNCTION test()
RETURNS SETOF test_table AS
$BODY$
DECLARE
BEGIN
RETURN QUERY
SELECT * FROM test_table WHERE value='a';
IF NOT FOUND THEN
RETURN QUERY
SELECT * FROM test_table WHERE value='b';
END IF;
RETURN;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE;
select * from test()
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Michal szymanski" <szymanskim(at)datera(dot)pl> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #4516: FOUND variable does not work after RETURN QUERY |
Date: | 2008-11-06 17:22:51 |
Message-ID: | 172.1225992171@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
"Michal szymanski" <szymanskim(at)datera(dot)pl> writes:
> Description: FOUND variable does not work after RETURN QUERY
The list of statements that set FOUND is here:
http://www.postgresql.org/docs/8.3/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-DIAGNOSTICS
RETURN isn't one of them.
regards, tom lane
From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Michal szymanski" <szymanskim(at)datera(dot)pl>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #4516: FOUND variable does not work after RETURN QUERY |
Date: | 2008-11-06 17:48:02 |
Message-ID: | 162867790811060948y3923dba6if4fc5ccd16cc5ebf@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
Hello
2008/11/6 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> "Michal szymanski" <szymanskim(at)datera(dot)pl> writes:
>> Description: FOUND variable does not work after RETURN QUERY
>
> The list of statements that set FOUND is here:
> http://www.postgresql.org/docs/8.3/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-DIAGNOSTICS
>
> RETURN isn't one of them.
>
> regards, tom lane
>
It should be enhanced - my initial proposal of return query expected
so return query is last statement, that isn't now. So we could add
this check there.
regards
Pavel Stehule
> --
> 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
>
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | "Michal szymanski" <szymanskim(at)datera(dot)pl>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #4516: FOUND variable does not work after RETURN QUERY |
Date: | 2008-11-06 18:19:31 |
Message-ID: | 3904.1225995571@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
"Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2008/11/6 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> RETURN isn't one of them.
> It should be enhanced - my initial proposal of return query expected
> so return query is last statement, that isn't now. So we could add
> this check there.
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.
regards, tom lane
From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Michal szymanski" <szymanskim(at)datera(dot)pl>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #4516: FOUND variable does not work after RETURN QUERY |
Date: | 2008-11-06 21:18:35 |
Message-ID: | 162867790811061318n102285b2lf4217e25c56f98df@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
2008/11/6 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 2008/11/6 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> RETURN isn't one of them.
>
>> It should be enhanced - my initial proposal of return query expected
>> so return query is last statement, that isn't now. So we could add
>> this check there.
>
> 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.
>
It's should do some problems, but I belive much less than change of
casting or tsearch2 integration. And actually it's not ortogonal.
Every not dynamic statement change FOUND variable.
regards
Pavel Stehule
> regards, tom lane
>
From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #4516: FOUND variable does not work after RETURN QUERY |
Date: | 2008-11-10 10:13:03 |
Message-ID: | 87tzafevo0.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
>>>>> "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)
From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Andrew Gierth" <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | pgsql-bugs(at)postgresql(dot)org, "postgres hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BUG #4516: FOUND variable does not work after RETURN QUERY |
Date: | 2008-11-13 11:00:58 |
Message-ID: | 162867790811130300p47af523dq2857b8299db03436@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
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 | Content-Type | Size |
---|---|---|
returnquery.diff | text/x-patch | 3.4 KB |
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 |
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: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, 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 23:03:35 |
Message-ID: | 3134.1231542215@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Uh, is this ready to be applied?
I don't think any consensus has been reached on changing this behavior.
regards, tom lane
From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Bruce Momjian" <bruce(at)momjian(dot)us>, "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>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Subject: | Re: [HACKERS] BUG #4516: FOUND variable does not work after RETURN QUERY |
Date: | 2009-01-10 08:51:12 |
Message-ID: | 162867790901100051x54fcca27n86c28304469c2931@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
Hello
2009/1/10 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> Uh, is this ready to be applied?
>
> I don't think any consensus has been reached on changing this behavior.
>
> regards, tom lane
>
I thing, so this is bug - RETURN QUERY has to supply FOR SELECT LOOP
RETURN NEXT pattern.
My first patch expected so RETURN QUERY is final statement, so I don't
solve FOUND variable, but Heikki changed this behave.
Without correct FOUND behave we can't to use RETURN QUERY for following pattern
RETURN QUERY some;
IF FOUND THEN RETURN; END IF;
RETURN QUERY some_other;
RETURN;
regards
Pavel Stehule
From: | "Robert Haas" <robertmhaas(at)gmail(dot)com> |
---|---|
To: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "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>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Subject: | Re: [HACKERS] BUG #4516: FOUND variable does not work after RETURN QUERY |
Date: | 2009-01-10 13:18:51 |
Message-ID: | 603c8f070901100518j6bd99bdq80caa0dde7fce994@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
> 2009/1/10 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>>> Uh, is this ready to be applied?
>>
>> I don't think any consensus has been reached on changing this behavior.
>
> I thing, so this is bug - RETURN QUERY has to supply FOR SELECT LOOP
> RETURN NEXT pattern.
>
> My first patch expected so RETURN QUERY is final statement, so I don't
> solve FOUND variable, but Heikki changed this behave.
>
> Without correct FOUND behave we can't to use RETURN QUERY for following pattern
>
> RETURN QUERY some;
> IF FOUND THEN RETURN; END IF;
> RETURN QUERY some_other;
> RETURN;
+1. I can't imagine it's good for this to be randomly inconsistent.
...Robert
From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, 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-10 18:30:12 |
Message-ID: | 4968E934.7080400@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
Pavel Stehule wrote:
> My first patch expected so RETURN QUERY is final statement, so I don't
> solve FOUND variable, but Heikki changed this behave.
Me? I don't recall doing anything related to this.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "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-10 21:17:46 |
Message-ID: | 162867790901101317y50c78a56ya157778c1b8a3621@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
2009/1/10 Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>:
> Pavel Stehule wrote:
>>
>> My first patch expected so RETURN QUERY is final statement, so I don't
>> solve FOUND variable, but Heikki changed this behave.
>
> Me? I don't recall doing anything related to this.
>
I have to look to archive, maybe Peter.
Pavel
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
>
From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Subject: | Re: [HACKERS] BUG #4516: FOUND variable does not work after RETURN QUERY |
Date: | 2009-02-04 18:32:47 |
Message-ID: | 200902041832.n14IWl001637@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
Robert Haas wrote:
> > 2009/1/10 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> >> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> >>> Uh, is this ready to be applied?
> >>
> >> I don't think any consensus has been reached on changing this behavior.
> >
> > I thing, so this is bug - RETURN QUERY has to supply FOR SELECT LOOP
> > RETURN NEXT pattern.
> >
> > My first patch expected so RETURN QUERY is final statement, so I don't
> > solve FOUND variable, but Heikki changed this behave.
> >
> > Without correct FOUND behave we can't to use RETURN QUERY for following pattern
> >
> > RETURN QUERY some;
> > IF FOUND THEN RETURN; END IF;
> > RETURN QUERY some_other;
> > RETURN;
>
> +1. I can't imagine it's good for this to be randomly inconsistent.
So should this be applied or just kept for 8.5?
--
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: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Subject: | Re: [HACKERS] BUG #4516: FOUND variable does not work after RETURN QUERY |
Date: | 2009-02-04 19:44:51 |
Message-ID: | 603c8f070902041144u4fa16584qf34e62c4f57aa69c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
On Wed, Feb 4, 2009 at 1:32 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Robert Haas wrote:
>> > 2009/1/10 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> >> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> >>> Uh, is this ready to be applied?
>> >>
>> >> I don't think any consensus has been reached on changing this behavior.
>> >
>> > I thing, so this is bug - RETURN QUERY has to supply FOR SELECT LOOP
>> > RETURN NEXT pattern.
>> >
>> > My first patch expected so RETURN QUERY is final statement, so I don't
>> > solve FOUND variable, but Heikki changed this behave.
>> >
>> > Without correct FOUND behave we can't to use RETURN QUERY for following pattern
>> >
>> > RETURN QUERY some;
>> > IF FOUND THEN RETURN; END IF;
>> > RETURN QUERY some_other;
>> > RETURN;
>>
>> +1. I can't imagine it's good for this to be randomly inconsistent.
>
> So should this be applied or just kept for 8.5?
Well, *I* think it should be applied. But YMMV.
...Robert
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: BUG #4516: FOUND variable does not work after RETURN QUERY |
Date: | 2009-02-05 15:26:04 |
Message-ID: | 200902051526.n15FQ4E21836@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
Pavel Stehule wrote:
> I am sending patch, that adds FOUND and GET DIAGNOSTICS support for
> RETURN QUERY statement
Updated patch attached and applied. Thanks.
---------------------------------------------------------------------------
>
> 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-bugs mailing list (pgsql-bugs(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
--
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. +
Attachment | Content-Type | Size |
---|---|---|
/rtmp/diff | text/x-diff | 4.3 KB |