From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Changed SRF in targetlist handling |
Date: | 2016-08-22 21:43:33 |
Message-ID: | 20160822214333.vdhuilh6fusnkner@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2016-08-22 16:20:58 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2016-08-17 17:41:28 -0700, Andres Freund wrote:
> >> Tom, do you think this is roughly going in the right direction?
>
> I've not had time to look at this patch, I'm afraid. If you still
> want me to, I can make time in a day or so.
That'd greatly be appreciated. I think polishing the POC up to
committable patch will be a considerable amount of work, and I'd like
design feedback before that.
> > I'm working on these. Atm ExecMakeTableFunctionResult() resides in
> > execQual.c - I'm inlining it into nodeFunctionscan.c now, because
> > there's no other callers, and having it separate seems to bring no
> > benefit.
>
> > Please speak soon up if you disagree.
>
> I think ExecMakeTableFunctionResult was placed in execQual.c because
> it seemed to belong there alongside the support for SRFs in tlists.
> If that's going away then there's no good reason not to move the logic
> to where it's used.
Cool, then we agree.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2016-08-22 21:43:40 | Re: Logical decoding of sequence advances, part II |
Previous Message | Peter Geoghegan | 2016-08-22 21:43:13 | Re: Parallel tuplesort (for parallel B-Tree index creation) |