Re: plpgsql EXECUTE will not set FOUND

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. :-)

> 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