Andres Freund <and...@anarazel.de> writes: > On 2017-02-01 23:27:36 -0500, Tom Lane wrote: >> I think the appropriate fix is that, once split_pathtarget_at_srfs() has >> computed a tentative list of SRFs it needs to evaluate, it has to make a >> second pass to see if any of them match expressions that were assigned to >> the next level down. This is pretty annoying, but we'd only have to do it >> if target_contains_srfs and context.nextlevel_contains_srfs are both true, >> which will be a negligibly small fraction of queries in practice.
> Hm. Can't really come up with something better, but I'm kinda tired > too... I wrote a patch along that line, and was just about ready to commit it when I realized that really this is all wrong. Fixing it this way handles the case of regression=# select generate_series(1,3), generate_series(1,3) + 1; generate_series | ?column? -----------------+---------- 1 | 2 2 | 3 3 | 4 (3 rows) which is what you got before v10, because the two SRFs ran in lockstep despite being at different expression nesting levels. However, consider regression=# select generate_series(1,3), generate_series(2,4) + 1; generate_series | ?column? -----------------+---------- 1 | 3 2 | 3 3 | 3 1 | 4 2 | 4 3 | 4 1 | 5 2 | 5 3 | 5 (9 rows) That's *not* what you got before: regression=# select generate_series(1,3), generate_series(2,4) + 1; generate_series | ?column? -----------------+---------- 1 | 3 2 | 4 3 | 5 (3 rows) Really the problem here is that split_pathtarget_at_srfs is completely wrong about how to assign SRFs to different levels in a stack of ProjectSet nodes. It's doing that according to each SRF's top-down nesting level, but it needs to do it bottom-up, so that a SRF is evaluated in the k'th step if there are k-1 nested levels of SRFs in its arguments. This is doable, but I think the routine will have to be completely rewritten not just hacked around the edges. Off to do that ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers