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

On 2017-02-01 23:27:36 -0500, Tom Lane wrote:
> I wrote:
> > Andres Freund <andres(at)anarazel(dot)de> writes:
> >> Tom, do you have an opinion?
>
> > Yes, it's broken. split_pathtarget_at_srfs seems to be doing the right
> > thing, but then something later is recombining the last two steps.
>
> Ah, no, I take that back: split_pathtarget_at_srfs is doing the wrong
> thing.

Yea, that's what I thought.

> Nothing's broken quite yet, but when we get to setrefs.c, it replaces
> *both* occurrences of g(x) with Vars referencing the g(x) output from
> the next level down. So now we have the tlist of the upper ProjectSet
> node as "f(Var), Var" and ProjectSet complains that it has no SRF to
> evaluate.

But I'd missed part of that subtlety.

> 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...

> Or we could take out that Assert in nodeProjectSet.c. But that seems
> like a hack not a fix.

Yea, I don't like that much.

> I'm pretty tired but I'll work on a fix tomorrow.

Cool.

Greetings,

Andres Freund