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.
regards, tom lane
