Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch
Date
Msg-id 14130.1427035560@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-bugs
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> 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...

Yeah.  You could put "OFFSET 0" into the sub-select if you want to ensure
it will not be flattened.

> The flatten would work if the result could be cached...it is defined to
> be immutable...but that would not be reliable generally...

Note that "immutable" effectively means "having no side-effects of
interest", so emitting a NOTICE from such a function is really cheating.
Another solution would be to mark the function VOLATILE.

            regards, tom lane

pgsql-bugs by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch
Next
From: "David G. Johnston"
Date:
Subject: Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch