Re: plpgsql EXECUTE will not set FOUND

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, PGDG <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plpgsql EXECUTE will not set FOUND
Date: 2009-11-10 02:01:14
Message-ID: 200911100201.nAA21El21324@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)stehule(at)gmail(dot)com> wrote:
> > 2009/10/23 Robert Haas <robertmhaas(at)gmail(dot)com>:
> >> On Fri, Oct 23, 2009 at 10:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> >>>> On Fri, Oct 23, 2009 at 9:52 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
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. +

Attachment Content-Type Size
/rtmp/diff text/x-diff 947 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-11-10 03:03:22 Re: Hot Standby and 64+ subxids (was COPY enhancements)
Previous Message Andrew Dunstan 2009-11-10 01:01:51 Re: Hot Standby and 64+ subxids (was COPY enhancements)