Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch
От | Tom Lane |
---|---|
Тема | Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch |
Дата | |
Msg-id | 14130.1427035560@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch
|
Список | 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 по дате отправления: