On Sunday, March 22, 2015, Paragon Corporation <lr@pcorp.us> wrote:
>
> SELECT v[1] As v1, v[2] As v2, v[3] As v3
> FROM
> (SELECT dummy_notice(1,2,3) As v) As t;
>
>
I suspect Tom's optimization:
http://git.postgresql.org/pg/commitdiff/f4abd0241de20d5d6a79b84992b9e88603d44134
is flattening the array returning function into the select-list of the
outer query so it effectively reads:
Select Dummy_notice(1,2,3)[1], dummy_notice(1,2,3)[2], etc...
The flatten would work if the result could be cached...it is defined to
be immutable...but that would not be reliable generally...
The more complex PostGIS query simply appears to Simply be multiple nested
functions but still with all constants. I guess the only easy way to not
pass constants would be to use a CTE and use an embedded scalar subquery to
pull from it. From the commit the lack of a from clause is the trigger so
putting the cte in a from would remove the optimization instead of proving
that the correct behavior is applied even if the arguments to the
select-list function are not literals.
Apologies in advance if this is a red herring...
David J.