Re: plpgsql EXECUTE will not set FOUND - Mailing list pgsql-hackers

I have applied the attached patch to document that FOUND is not affected
by EXECUTE, while GET DIAGNOSTICS is.

---------------------------------------------------------------------------

Robert Haas wrote:
> On Fri, Oct 23, 2009 at 12:05 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> > 2009/10/23 Robert Haas <robertmhaas@gmail.com>:
> >> On Fri, Oct 23, 2009 at 10:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >>> Robert Haas <robertmhaas@gmail.com> writes:
> >>>> On Fri, Oct 23, 2009 at 9:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >>>>> [shrug...] ?There is also real user demand for not silently breaking
> >>>>> code that works now, which is what we risk anytime we change the set
> >>>>> of statements that can set FOUND.
> >>>
> >>>> We've had this discussion before and I'm still unpersuaded by your
> >>>> position. ?I *never* write "IF FOUND THEN" except immediately after
> >>>> the statement where I expect that variable to be set, and I submit
> >>>> that anyone who who does write code that relies on certain statements
> >>>> not setting FOUND is, IMO, depending on a bug. ?We don't and shouldn't
> >>>> have a policy of making future PostgreSQL releases bug-compatible with
> >>>> previous releases.
> >>>
> >>> This position is nonsense for two reasons:
> >>>
> >>> 1. It can hardly be considered a bug that FOUND is set only by the
> >>> statements that the documentation specifically states are the only ones
> >>> it is set by.
> >>
> >> OK, it's not a bug: it's a misfeature. ?:-)
> >
> > Isn't this behave shared with PL/SQL? In some environments the dynamic
> > queries are external - so there wasn't possibility to get return
> > state. I afraid so somewhere this feature was extensively used - I
> > dislike this feature too, but I agree with Tom - this is small
> > problem, and it is better do nothing.
> >
> > What about to add new flag to EXECUTE?
> >
> > or create execute function, that returns found
> >
> > like
> >
> > execute('SELECT ....' INTO ... USING ...)?
> >
> > it's obscure too.
>
> Yeah, I mean, if the consensus is that we shouldn't change this, then
> people will just have to work around it using some other method, like
> GET DIAGNOSTICS.  It's not really worth adding a whole separate way of
> doing this just to set FOUND.  However, it would be worth documenting
> the workaround, because I can see where the OP was left scratching his
> head.
>
> ...Robert
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/plpgsql.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/plpgsql.sgml,v
retrieving revision 1.143
diff -c -c -r1.143 plpgsql.sgml
*** doc/src/sgml/plpgsql.sgml    29 Sep 2009 20:05:29 -0000    1.143
--- doc/src/sgml/plpgsql.sgml    10 Nov 2009 01:55:33 -0000
***************
*** 1366,1372 ****

       <literal>FOUND</literal> is a local variable within each
       <application>PL/pgSQL</application> function; any changes to it
!      affect only the current function.
      </para>

     </sect2>
--- 1366,1374 ----

       <literal>FOUND</literal> is a local variable within each
       <application>PL/pgSQL</application> function; any changes to it
!      affect only the current function.  <literal>FOUND</literal> is not
!      affected by <literal>EXECUTE</literal>, while <command>GET
!      DIAGNOSTICS</command> is effected.
      </para>

     </sect2>