Re: Any reason not to return row_count in cursor of plpgsql? - Mailing list pgsql-hackers

From David Fetter
Subject Re: Any reason not to return row_count in cursor of plpgsql?
Date
Msg-id 20090327210544.GD19621@fetter.org
Whole thread Raw
In response to Re: Any reason not to return row_count in cursor of plpgsql?  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
On Fri, Mar 27, 2009 at 08:59:29PM +0000, Andrew Gierth wrote:
> >>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
> 
>  > Andrew Gierth <andrew@tao11.riddles.org.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@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com

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


pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: Any reason not to return row_count in cursor of plpgsql?
Next
From: Bruce Momjian
Date:
Subject: Re: typedefs for indent