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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Paragon Corporation <lr(at)pcorp(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 14:46:00
Message-ID: 14130.1427035560@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> 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...

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2015-03-22 15:05:29 Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch
Previous Message David G. Johnston 2015-03-22 09:07:35 Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch