Robert Haas <robertmh...@gmail.com> writes:
> On Fri, Oct 23, 2009 at 9:52 AM, Tom Lane <t...@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.
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.
Any change here is *not* a bug fix, it is a change of clearly documented
and not-obviously-unreasonable behavior. We have to take seriously the
likelihood that it will break existing code. If there were a way to
flag such breakage I would be happier about changing it; but as Andrew
already noted, there doesn't seem to be any way to find affected code
except painful manual review.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
