Re: Any reason not to return row_count in cursor of plpgsql?

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: Any reason not to return row_count in cursor of plpgsql?
Дата
Msg-id 877i2bi6rc.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: Any reason not to return row_count in cursor of plpgsql?  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Any reason not to return row_count in cursor of plpgsql?
Re: Any reason not to return row_count in cursor of plpgsql?
Список pgsql-hackers
>>>>> "Bruce" == Bruce Momjian <bruce@momjian.us> writes:
>> hi all,>> >> I read the code that it seems easy for the cursor in plpgsql to>> return ROW_COUNT after MOVE LAST etc.
TheSPI_processed variable>> already there, but didn't put it into estate structure, any reason>> for that?>> >> thanks
andbest regards
 
Bruce> Sorry, we have decided against this change because it mightBruce> break existing applications.

As they say on wikipedia, [citation needed]

GET DIAGNOSTICS ROW_COUNT is documented as working for all commands;
if it doesn't work for MOVE (and FETCH), that's a bug. It might be one
that's not appropriate to backpatch, but that's no excuse for not
fixing it in a new release.

It's especially egregious in that MOVE _does_ set FOUND.

diff -c -r1.235 pl_exec.c
*** pl_exec.c    23 Feb 2009 10:03:22 -0000    1.235
--- pl_exec.c    27 Mar 2009 10:44:08 -0000
***************
*** 3368,3373 ****
--- 3368,3375 ----         exec_set_found(estate, n != 0);     } 
+     estate->eval_processed = n;
+      return PLPGSQL_RC_OK; } 
-- 
Andrew (irc:RhodiumToad)


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Gierth
Дата:
Сообщение: Re: 8.4 release notes proof reading 1/2
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: psql: Make tab completion work for ANALYZE VERBOSE ...