Andres Freund <andres@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