[prev in list] [next in list] [prev in thread] [next in thread]
List: pgsql-bugs
Subject: Re: [BUGS] Multiple evaluation of single reference to function with out parameters
From: Pavel Stehule <pavel.stehule () gmail ! com>
Date: 2017-09-23 3:01:29
Message-ID: CAFj8pRAPhebN0L_m_wm+0ebf2691LKOQKJ08+RiBHrawc1hP3A () mail ! gmail ! com
[Download RAW message or body]
2017-09-23 4:49 GMT+02:00 Joel Hoffman <joel.hoffman@gmail.com>:
> Thanks for the response. Here's the documentation reference:
>
> https://www.postgresql.org/docs/9.6/static/rowtypes.html#ROWTYPES-USAGE
>
> Not a bug, but I do think it's very surprising behavior.
>
yes, but the fix is very simple - you just need only one level of nested
query more - or you call function from FROM clause.
The reason of this behave is given by implementation, that is very simple.
Nobody had too issues with it and nobody sent a patch to change it.
Regards
Pavel
> Joel
>
>
> On Fri, Sep 22, 2017 at 5:22 PM, David G. Johnston <
> david.g.johnston@gmail.com> wrote:
>
>> On Friday, September 22, 2017, Joel Hoffman <joel.hoffman@gmail.com>
>> wrote:
>>
>>> If I create a function with more than one out parameter, and then refer
>>> to it inside parentheses as a record, e.g. select (function()).*, the
>>> function appears to be evaluated multiple times, once for every column
>>> returned. This seems to be true regardless of whether it's defined as
>>> volatile or immutable.
>>>
>>> ...
>>
>>> As far as I can tell, this behavior has been the same since at least
>>> version 8.2 and up through 10 beta 4, but I can't find any references to it
>>> and it seems very surprising. It could certainly cause unexpected results
>>> if the function has side effects. Is this a bug?
>>>
>>>
>> It is not a bug or likely to be fixed. LATERAL makes the need for
>> function invocation in the manner you describe nearly unnecessary and you
>> can use OFFSET 0 in other cases to put the function call in a subquery and
>> place the (composite).* expressionin the upper-level.
>>
>> There is a cautionary note somewhere in docs about this. It is a parser
>> byproduct. The star gets expanded at parse time to individual and
>> independent column names. What happens is exactly what you'd expect if you
>> tried to write the query without resorting to using ".*"
>>
>> David J.
>>
>
>
[Attachment #3 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-09-23 \
4:49 GMT+02:00 Joel Hoffman <span dir="ltr"><<a \
href="mailto:joel.hoffman@gmail.com" \
target="_blank">joel.hoffman@gmail.com</a>></span>:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div><div>Thanks for the response. \
Here's the documentation reference: <br><br><a \
href="https://www.postgresql.org/docs/9.6/static/rowtypes.html#ROWTYPES-USAGE" \
target="_blank">https://www.postgresql.org/<wbr>docs/9.6/static/rowtypes.html#<wbr>ROWTYPES-USAGE</a><br><br></div>Not \
a bug, but I do think it's very surprising behavior. \
<br></div></div></blockquote><div><br></div><div>yes, but the fix is very simple - \
you just need only one level of nested query more - or you call function from FROM \
clause.</div><div><br></div><div>The reason of this behave is given by \
implementation, that is very simple. Nobody had too issues with it and nobody sent a \
patch to change it.</div><div><br></div><div>Regards</div><div><br></div><div>Pavel<br></div><div><br></div><div><br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div \
dir="ltr"><div><br></div>Joel<br><div><div><br></div></div></div><div \
class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 22, 2017 at 5:22 PM, \
David G. Johnston <span dir="ltr"><<a href="mailto:david.g.johnston@gmail.com" \
target="_blank">david.g.johnston@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><span>On Friday, September 22, 2017, Joel Hoffman <<a \
href="mailto:joel.hoffman@gmail.com" target="_blank">joel.hoffman@gmail.com</a>> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><div dir="ltr"><div>If I create a function with more \
than one out parameter, and then refer to it inside parentheses as a record, e.g. \
select (function()).*, the function appears to be evaluated multiple times, once for \
every column returned. This seems to be true regardless of whether it's defined \
as volatile or immutable.<br></div><div><br></div></div></blockquote></span><div>... \
</div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><div dir="ltr"><div>As far as I can tell, this behavior \
has been the same since at least version 8.2 and up through 10 beta 4, but I \
can't find any references to it and it seems very surprising. It could certainly \
cause unexpected results if the function has side effects. Is this a \
bug?</div><div><br></div></div></blockquote><div><br></div></span><div>It is not a \
bug or likely to be fixed. LATERAL makes the need for function invocation in the \
manner you describe nearly unnecessary and you can use OFFSET 0 in other cases to \
put the function call in a subquery and place the (composite).* expressionin the \
upper-level.</div><div><br></div><div>There is a cautionary note somewhere in docs \
about this. It is a parser byproduct. The star gets expanded at parse time to \
individual and independent column names. What happens is exactly what you'd \
expect if you tried to write the query without resorting to using \
".*"</div><div><br></div><div>David J.</div> </blockquote></div><br></div>
</blockquote></div><br></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic