On Fri, Oct 23, 2009 at 10:50 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
