Re: upper planner path-ification

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>> If there's interest, we could do that specific task as part of>> adding hashagg support for grouping sets (which
wouldotherwise make>> it even longer), or as preparatory work for that.
 
Tom> I think that refactoring without changing anything about the wayTom> it works will be painful and probably
ultimatelya dead end.  AsTom> an example, the current_pathkeys local variable is state that'sTom> needed throughout
thatprocess, so you'd need some messy notationTom> to pass it around (unless you stuck it into PlannerRoot, whichTom>
wouldbe ugly too).  But that would go away in a path-ifiedTom> universe, because each Path would be marked as to its
outputsortTom> order.  More, a lot of the code that you'd be relocating is codeTom> that we should be trying to get rid
ofaltogether, not justTom> relocate (to wit all the stuff that does cost-based comparisons ofTom> alternatives).
 
Tom> So I'm all for refactoring, but I think it will happen as a naturalTom> byproduct of path-ification, and otherwise
wouldbe rather forced.
 

Hrm, ok. So for the near future, we should leave it more or less as-is?
We don't have a timescale yet, but it's our intention to submit a
hashagg support patch for grouping sets as soon as time permits.

-- 
Andrew (irc:RhodiumToad)