From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Any reason not to return row_count in cursor of plpgsql? |
Date: | 2009-04-02 19:20:55 |
Message-ID: | 200904021920.n32JKtF00619@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thanks, patch applied.
---------------------------------------------------------------------------
Andrew Gierth wrote:
> >>>>> "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)
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2009-04-02 19:26:34 | Re: Path case sensitivity on windows |
Previous Message | Andrew Gierth | 2009-04-02 19:13:02 | Re: Crash in gist insertion on pathological box data |