Re: plpgsql EXECUTE will not set FOUND - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: plpgsql EXECUTE will not set FOUND
Date
Msg-id 4AE1BE7F.5060300@dunslane.net
Whole thread Raw
In response to Re: plpgsql EXECUTE will not set FOUND  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers

Robert Haas wrote:
> On Fri, Oct 23, 2009 at 9:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>   
>> Dimitri Fontaine <dfontaine@hi-media.com> writes:
>>     
>>> I'll go search for more, meantime I'll just add the main goal of this
>>> new thread is to have -hackers know there is a real user demand for
>>> having EXECUTE set FOUND the same way it sets GET DIAGNOSTIC.
>>>       
>> [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.
>
>
>   

I agree that  doing that is bad practice. I disagree that it's a bug. 
And if it is, and we change it, then locating all the places where the 
bug might occur will be a nightmare. In effect it means you'll need to 
review every single use of FOUND in your code (possibly hundreds of 
thousands or millions of lines) to make sure you're not accidentally 
relying on the behaviour. No thanks.

cheers

andrew


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Using views for row-level access control is leaky
Next
From: Tom Lane
Date:
Subject: Re: pre-proposal: type interfaces