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

On Fri, Mar 27, 2009 at 08:59:29PM +0000, Andrew Gierth wrote:
> >>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> > Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> >> GET DIAGNOSTICS ROW_COUNT is documented as working for all commands;
> >> if it doesn't work for MOVE (and FETCH), that's a bug.
>
> Tom> Or a documentation problem. I don't see any claim that it works for
> Tom> "all commands" anyway.
>
> "This command allows retrieval of system status indicators. Each item
> is a key word identifying a state value to be assigned to the
> specified variable (which should be of the right data type to receive
> it). The currently available status items are ROW_COUNT, the number of
> rows processed by the last SQL command sent down to the SQL engine,
> and RESULT_OID, the OID of the last row inserted by the most recent
> SQL command. Note that RESULT_OID is only useful after an INSERT
> command into a table containing OIDs."
>
> The idea that fetch/move should _intentionally_ not set ROW_COUNT is
> beyond ludicrous.

It's a flat-out bug not to have FETCH/MOVE set this.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate