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  ("Pavel Stehule" <pavel.stehule@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Getting "FATAL: unexpected data beyond EOF in block 1 of relation 1663/1/1255/0" on Mac OS during initdb
Следующее
От: Zdenek Kotala
Дата:
Сообщение: Re: BUG #4494: Memory leak in pg_regress.c