I think not going through nodeModifyTable and having a separate nodeMerge.c makes sense. It might result in some code being duplicated, but I suppose that code can be shared (wrapped as a function, moved to some file shared by the two nodes). I wouldn't expect the result to be particularly ugly, at least not compared to how nodeModifyTable is twisted with the current patch.
Ok. I will try that approach again. In the meanwhile, I am posting a rebased version. There had been quite a lot changes on partitioning side and that caused non-trivial conflicts. I noticed a couple of problems during the rebase, but I haven't attempted to address them fully yet, since I think a detailed review at some point might require us to change that anyways.
- Noticed that partColsUpdated is not set correctly in case of MERGE since we never get to call expand_partitioned_rtentry() for the partition table in case of MERGE. This right now does not cause significant problem, since we initialise the required states by other means. But we should fix this.
- I am not entirely sure if the tuple-conversion business is bug-free for MERGE, post this rebase. Since this code has changed quite a bit in the master, I will have another look and check. The tests do not show any issues, but that could also be because of lack of tests in this area with respect to MERGE.
- I am not sure if I adopted the slot related changes introduced by 1a0586de3657cd35581f0639c87d5050c6197bb7.