On Thu, Oct 14, 2010 at 11:34 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> I rather wonder if we don't want two separate >> execution-time node types anyway, since what Append does seems >> significantly different from Merge (and MergeAppend would be just a >> misnomer). > > I've been working on this patch, and have gotten the executor side split > out as a new node type. That adds something like 600 lines of > boilerplate code in various places, but I think it's well worthwhile to > get rid of the spaghetti-code effect of retail checks to see which kind > of Append we're dealing with. (Greg didn't catch all the places that > needed to distinguish, anyway.) > > I did run into a problem with my plan to call the new node type "Merge": > the planner is already using "MergePath" as the name for the Path struct > that is precursor to a MergeJoin. For the moment I'm calling the new > node type MergeAppend, but as mentioned I feel that that's a bit of a > misnomer. > > The only good alternative that I can think of is to rename MergePath to > MergeJoinPath (and then for consistency probably also HashPath to > HashJoinPath and NestPath to NestLoopPath). While that wouldn't touch > a huge number of files, it seems to carry some risk of breaking pending > patches, and anyway those are names that go back to Berkeley days so > people are used to 'em. > > Anybody have a strong feeling about what to call these things? > At the moment I'm leaning to sticking with MergeAppend, but if we > decide to rename it it'd probably be better to do so before committing.
I don't like the idea of renaming the join nodes. Both the code churn and the possibility of confusing long-time users seem undesirable. Let's just stick with MergeAppend. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
