From: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | mike(dot)lang1010(at)gmail(dot)com, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #13798: Unexpected multiple exection of user defined function with out parameters |
Date: | 2015-12-08 18:31:33 |
Message-ID: | CACjxUsPyLunV5sr1rZrRP8kVvH9ZSoAzRLQSsXNPuKCqwWAM5w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, Dec 8, 2015 at 10:24 AM, David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> On Tue, Dec 8, 2015 at 9:08 AM, Kevin Grittner <kgrittn(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-12-08 19:04:54 | Re: BUG #13798: Unexpected multiple exection of user defined function with out parameters |
Previous Message | Tom Lane | 2015-12-08 18:16:38 | Re: BUG #13796: ALTER TYPE DROP COLUMN -- unexpected behavior ? |