On 2017-02-01 23:27:36 -0500, Tom Lane wrote:
> I wrote:
> > Andres Freund <andres@anarazel.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