On Fri, Oct 23, 2009 at 12:05 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 2009/10/23 Robert Haas <robertmhaas@gmail.com>:
>> On Fri, Oct 23, 2009 at 10:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Robert Haas <robertmhaas@gmail.com> writes:
>>>> On Fri, Oct 23, 2009 at 9:52 AM, Tom Lane <tgl@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. :-)
>
> Isn't this behave shared with PL/SQL? In some environments the dynamic
> queries are external - so there wasn't possibility to get return
> state. I afraid so somewhere this feature was extensively used - I
> dislike this feature too, but I agree with Tom - this is small
> problem, and it is better do nothing.
>
> What about to add new flag to EXECUTE?
>
> or create execute function, that returns found
>
> like
>
> execute('SELECT ....' INTO ... USING ...)?
>
> it's obscure too.
Yeah, I mean, if the consensus is that we shouldn't change this, then
people will just have to work around it using some other method, like
GET DIAGNOSTICS. It's not really worth adding a whole separate way of
doing this just to set FOUND. However, it would be worth documenting
the workaround, because I can see where the OP was left scratching his
head.
...Robert