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 |
Thread: | |
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 | Date | Subject | |
---|---|---|---|
Next Message | Zdenek Kotala | 2008-11-10 12:31:50 | Re: BUG #4494: Memory leak in pg_regress.c |
Previous Message | Bruce Momjian | 2008-11-07 23:21:53 | Re: Re: [BUGS] libpq does not manage SSL callbacks properly when other libraries are involved. |
From | Date | Subject | |
---|---|---|---|
Next Message | KaiGai Kohei | 2008-11-10 10:21:38 | Updates of SE-PostgreSQL 8.4devel patches (r1206) |
Previous Message | Fujii Masao | 2008-11-10 09:45:27 | Re: Synchronous replication patch v1 |