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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)
Date: 2017-01-16 19:13:18
Message-ID: 21924.1484593998@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> That worked quite well. So we have a few questions, before I clean this
> up:

> - For now the node is named 'Srf' both internally and in explain - not
> sure if we want to make that something longer/easier to understand for
> others? Proposals? TargetFunctionScan? SetResult?

"Srf" is ugly as can be, and unintelligible. SetResult might be OK.

> - I continued with the division of Labor that Tom had set up, so we're
> creating one Srf node for each "nested" set of SRFs. We'd discussed
> nearby to change that for one node/path for all nested SRFs, partially
> because of costing. But I don't like the idea that much anymore. The
> implementation seems cleaner (and probably faster) this way, and I
> don't think nested targetlist SRFs are something worth optimizing
> for. Anybody wants to argue differently?

Not me.

> Comments?

Hard to comment on your other points without a patch to look at.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2017-01-16 19:30:02 Re: patch: function xmltable
Previous Message Tom Lane 2017-01-16 19:10:24 Re: check_srf_call_placement() isn't always setting p_hasTargetSRFs