On Thu, Oct 14, 2010 at 11:34 AM, Tom Lane <tgl@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