Re: BUG #4516: FOUND variable does not work after RETURN QUERY
От | Andrew Gierth |
---|---|
Тема | Re: BUG #4516: FOUND variable does not work after RETURN QUERY |
Дата | |
Msg-id | 87tzafevo0.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | BUG #4516: FOUND variable does not work after RETURN QUERY ("Michal szymanski" <szymanskim@datera.pl>) |
Ответы |
Re: BUG #4516: FOUND variable does not work after RETURN QUERY
|
Список | pgsql-bugs |
>>>>> "Pavel" == "Pavel Stehule" <pavel.stehule@gmail.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)
В списке pgsql-bugs по дате отправления: