Re: BUG #13798: Unexpected multiple exection of user defined function with out parameters - Mailing list pgsql-bugs

From Kevin Grittner
Subject Re: BUG #13798: Unexpected multiple exection of user defined function with out parameters
Date
Msg-id CACjxUsPyLunV5sr1rZrRP8kVvH9ZSoAzRLQSsXNPuKCqwWAM5w@mail.gmail.com
Whole thread Raw
In response to Re: BUG #13798: Unexpected multiple exection of user defined function with out parameters  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: BUG #13798: Unexpected multiple exection of user defined function with out parameters  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Tue, Dec 8, 2015 at 10:24 AM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> On Tue, Dec 8, 2015 at 9:08 AM, Kevin Grittner <kgrittn@gmail.com> wrote:

>> [...] * causes expansion to the following query:
>>
>> SELECT
>>     (reproducebehavior()).message1,
>>     (reproducebehavior()).message2,
>>     (reproducebehavior()).message3,
>>     (reproducebehavior()).message4;
>>
>> From that you can see why it is not surprising that the function is
>> executed once per OUT parameter, especially if it is VOLATILE.
>
> While you've explained how to see what is happening it doesn't remove
> the POLA violation that has occurred here.

I tend to think of x.* as being something that is resolved at parse
analysis time, before any consideration is given to how to execute;
thus, when x is a function I didn't find it at all astonishing that
it resolved as above.  If you think of * as a macro that expands in
the above manner before planning, the fact that it does not
optimize to a single call is not surprising for a VOLATILE
function; that is required behavior.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #13796: ALTER TYPE DROP COLUMN -- unexpected behavior ?
Next
From: Michael Lang
Date:
Subject: Re: BUG #13799: Unexpected multiple exection of user defined function with out parameters