Re: [HACKERS] Any reason not to return row_count in cursor of plpgsql?
Thanks, patch applied. --- Andrew Gierth wrote: Bruce == Bruce Momjian br...@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. 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 - 1.235 --- pl_exec.c 27 Mar 2009 10:44:08 - *** *** 3368,3373 --- 3368,3375 exec_set_found(estate, n != 0); } + estate-eval_processed = n; + return PLPGSQL_RC_OK; } -- Andrew (irc:RhodiumToad) -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Any reason not to return row_count in cursor of plpgsql?
Bruce == Bruce Momjian br...@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. 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 - 1.235 --- pl_exec.c 27 Mar 2009 10:44:08 - *** *** 3368,3373 --- 3368,3375 exec_set_found(estate, n != 0); } + estate-eval_processed = n; + return PLPGSQL_RC_OK; } -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Any reason not to return row_count in cursor of plpgsql?
Andrew Gierth and...@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. Or a documentation problem. I don't see any claim that it works for all commands anyway. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Any reason not to return row_count in cursor of plpgsql?
Tom == Tom Lane t...@sss.pgh.pa.us writes: Andrew Gierth and...@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. -- Andrew. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Any reason not to return row_count in cursor of plpgsql?
On Fri, Mar 27, 2009 at 08:59:29PM +, Andrew Gierth wrote: Tom == Tom Lane t...@sss.pgh.pa.us writes: Andrew Gierth and...@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 da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Any reason not to return row_count in cursor of plpgsql?
laser wrote: 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 Sorry, we have decided against this change because it might break existing applications. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Any reason not to return row_count in cursor of plpgsql?
laser wrote: 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? [ Sorry for the delay.] Would some tests how Oracle behaves in this case? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Any reason not to return row_count in cursor of plpgsql?
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 -laser -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
