Re: plpgsql EXECUTE will not set FOUND

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: plpgsql EXECUTE will not set FOUND
Дата
Msg-id 4AE1BE7F.5060300@dunslane.net
обсуждение исходный текст
Ответ на Re: plpgsql EXECUTE will not set FOUND  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: Using views for row-level access control is leaky
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pre-proposal: type interfaces