On 2017-02-01 23:27:36 -0500, Tom Lane wrote: > I wrote: > > Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
