Re: plpgsql EXECUTE will not set FOUND

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.

Regards
Pavel Stehule

>
>> 2. In order to use FOUND *at all* you must assume that it has got some
>> amount of stability.  "IF FOUND" is already assuming that the "IF"
>> statement didn't reset the flag before evaluating the expression.
>> Lots of other perfectly reasonable constructions assume that FOUND
>> will stay stable across "no op" statements.
>
> Sure.  I think there's a big difference between assuming that the word
> IF (or the intervening semicolon and/or whitespace) did not reset
> FOUND and assuming that it will not be reset by the execution of a
> dynamic SQL query.  The former is necessary for there to be any
> conceivable way of using FOUND; the latter is assuming that for some
> reason we want to treat dynamic SQL queries differently than static
> ones.
>
> ...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
>