On 2016-05-25 15:02:23 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.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.
I think that depends on how bug compatible we want to be. It seems
harder to get the (rather odd!) lockstep iteration behaviour between two
SRFS with the LATERAL approach?
tpch[6098][1]=# SELECT generate_series(1, 3), generate_series(1,3);
┌─────────────────┬─────────────────┐
│ generate_series │ generate_series │
├─────────────────┼─────────────────┤
│ 1 │ 1 │
│ 2 │ 2 │
│ 3 │ 3 │
└─────────────────┴─────────────────┘
(3 rows)
tpch[6098][1]=# SELECT generate_series(1, 3), generate_series(1,4);
┌─────────────────┬─────────────────┐
│ generate_series │ generate_series │
├─────────────────┼─────────────────┤
│ 1 │ 1 │
│ 2 │ 2 │
│ 3 │ 3 │
│ 1 │ 4 │
│ 2 │ 1 │
│ 3 │ 2 │
│ 1 │ 3 │
│ 2 │ 4 │
│ 3 │ 1 │
│ 1 │ 2 │
│ 2 │ 3 │
│ 3 │ 4 │
└─────────────────┴─────────────────┘
(12 rows)
Regards,
Andres