Re: Changed SRF in targetlist handling
От | Andres Freund |
---|---|
Тема | Re: Changed SRF in targetlist handling |
Дата | |
Msg-id | 20160525191425.phleegljt35arnsx@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Changed SRF in targetlist handling (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Changed SRF in targetlist handling
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: