Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (wasChanged SRF in targetlist handling)
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (wasChanged SRF in targetlist handling) |
Дата | |
Msg-id | 20170117185346.z55d3jnsaf24yr4m@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 2017-01-17 13:43:38 -0500, Tom Lane wrote: > Although ... looking closer at Andres' patch, the new node type *is* > channeling Result, in the sense that it might or might not have any input > plan. This probably traces to what I wrote in September: > > + * XXX Possibly-temporary hack: if the subpath is a dummy ResultPath, > + * don't bother with it, just make a Result with no input. This avoids an > + * extra Result plan node when doing "SELECT srf()". Depending on what we > + * decide about the desired plan structure for SRF-expanding nodes, this > + * optimization might have to go away, and in any case it'll probably look > + * a good bit different. > > I'm not convinced that that optimization is worth preserving, but if we > keep it then ProjectSet isn't le mot juste here, any more than you'd want > to rename Result to Project without changing its existing > functionality. Right. I'd removed that, and re-added it; primarily because the plans looked more complex without it. After all, you'd thought it worth adding that hack ;) I'm happy with removing it again too. Andres
В списке pgsql-hackers по дате отправления: