Re: Any reason not to return row_count in cursor of plpgsql? - Mailing list 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)