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 по дате отправления: