Re: TRAP: FailedAssertion("!(hassrf)", File: "nodeProjectSet.c", Line: 180)

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