Andres Freund <and...@anarazel.de> writes: > On 2016-09-12 13:26:20 -0400, Tom Lane wrote: >> Stepping back a little bit ... way back at the start of this thread >> you muttered about possibly implementing tSRFs as a special pipeline >> node type, a la Result. That would have the same benefits in terms >> of being able to take SRF support out of the main execQual code paths. >> I, and I think some other people, felt that the LATERAL approach would >> be a cleaner answer --- but now that we're seeing some of the messy >> details required to make the LATERAL way work, I'm beginning to have >> second thoughts. I wonder if we should do at least a POC implementation >> of the other way to get a better fix on which way is really cleaner.
> I'm not particularly in love in restarting with a different approach. I > think fixing the ROWS FROM expansion is the only really painful bit, and > that seems like it's independently beneficial to allow for suppression > of expansion there. Um, I dunno. You've added half a thousand lines of not-highly-readable- nor-extensively-commented code to the planner; that certainly reaches *my* threshold of pain. I'm also growing rather concerned that the LATERAL approach is going to lock us into some unremovable incompatibilities no matter how much we might regret that later (and in view of how quickly I got my wrist slapped in <firstname.lastname@example.org>, I am afraid there may be more pushback awaiting us than we think). If we go with a Result-like tSRF evaluation node, then whether we change semantics or not becomes mostly a matter of what that node does. It could become basically a wrapper around the existing ExecTargetList() logic if we needed to provide backwards-compatible behavior. > I actually had started to work on a Result style approach, and I don't > think it turned out that nice. But I didn't complete it, so I might just > be wrong. It's also possible that it's easier now in the post-pathification code base than it was before. After contemplating my navel for awhile, it seems like the core of the planner code for a Result-like approach would be something very close to make_group_input_target(), plus a thing like pull_var_clause() that extracts SRFs rather than Vars. Those two functions, including their lengthy comments, weigh in at ~250 lines. Admittedly there'd be some boilerplate on top of that, if we invent a new plan node type rather than extending Result, but not all that much. If you like, I'll have a go at drafting a patch in that style. Do you happen to still have the executor side of what you did, so I don't have to reinvent that? regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers