Re: plpgsql EXECUTE will not set FOUND

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, PGDG <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plpgsql EXECUTE will not set FOUND
Date: 2009-10-23 14:32:31
Message-ID: 4AE1BE7F.5060300@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas wrote:
> On Fri, Oct 23, 2009 at 9:52 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Dimitri Fontaine <dfontaine(at)hi-media(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-10-23 14:34:34 Re: pre-proposal: type interfaces
Previous Message David Fetter 2009-10-23 14:24:23 Re: Using views for row-level access control is leaky