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: Changed SRF in targetlist handling |
Date: | 2016-05-25 19:02:23 |
Message-ID: | 4872.1464202943@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:
> On 2016-05-23 13:10:29 -0400, Tom Lane wrote:
>> Would that not lead to, in effect, duplicating all of execQual.c? The new
>> executor node would still have to be prepared to process all expression
>> node types.
> I don't think it necessarily has to. ISTM that if we add a version of
> ExecProject()/ExecTargetList() that continues returning multiple rows,
> we can make the knowledge about the one type of expression we allow to
> return multiple rows. That'd require a bit of uglyness to implement
> stuff like
> SELECT generate_series(1, 2)::text, generate_series(1, 2) * 5;
> etc. It seems we'd basically have to do one projection step for the
> SRFs, and then another for the rest. I'm inclined to think that's
> acceptable to get rid of a lot of the related uglyness.
[ shrug... ] That seems like it's morally equivalent to (but uglier than)
what I wanted to do, which is to teach the planner to rewrite the query to
put the SRFs into a lateral FROM item. Splitting the tlist into two
levels will work out to be exactly the same rewriting problem.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-05-25 19:13:23 | Re: pg_bsd_indent - improvements around offsetof and sizeof |
Previous Message | Andres Freund | 2016-05-25 18:57:12 | Re: Changed SRF in targetlist handling |