Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Paragon Corporation <lr(at)pcorp(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch
Date: 2015-03-22 09:07:35
Message-ID: CAKFQuwZtQxTcEQRpXk4Je9=1XSUSA40=BTi62M+GNH96P6dDgg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sunday, March 22, 2015, Paragon Corporation <lr(at)pcorp(dot)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.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2015-03-22 14:46:00 Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch
Previous Message Paragon Corporation 2015-03-22 08:28:49 Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch