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