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

>>>>> "Bruce" == Bruce Momjian <bruce(at)momjian(dot)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. The SPI_processed variable
>> already there, but didn't put it into estate structure, any reason
>> for that?
>>
>> thanks and best regards

Bruce> Sorry, we have decided against this change because it might
Bruce> 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)