Andres Freund <and...@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. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers