Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch
От | David G. Johnston |
---|---|
Тема | Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch |
Дата | |
Msg-id | CAKFQuwZtQxTcEQRpXk4Je9=1XSUSA40=BTi62M+GNH96P6dDgg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch ("Paragon Corporation" <lr@pcorp.us>) |
Ответы |
Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch
|
Список | pgsql-bugs |
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.
В списке pgsql-bugs по дате отправления: