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
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 |