Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Jan 17, 2017 at 1:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Using Result for two completely different things is a wart though. If we
>> had it to do over I think we'd define Result as a scan node that produces
>> rows from no input, and create a separate Project node for the case of
>> projecting from input tuples. People are used to seeing Result in EXPLAIN
>> output, so it's not worth the trouble of changing that IMO, but we don't
>> have to use it as a model for more node types.

> +1, although I think changing the existing node would be fine too if
> somebody wanted to do the work. It's not worth having that wart
> forever just to avoid whatever minor pain-of-adjustment might be
> involved.

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.

regards, tom lane