new patch of MERGE (merge_204) & a question about duplicated ctid

I have updated the MERGE patch for two main problems.

1. Support of system attributes in MERGE action expressions. 

    In old version of MERGE, I use the top join as the only RTE in var name space, during the transformation process in parser. It contains all the common attributes of source and target table but not the system attributes, such as oid. 

    Thus, if user specified system attributes in MERGE actions, error pops. In current version, the var name space is forced to be the target table RTE and source table RTE. So system attributes will be correctly transformed. 

2. fix the problem of dropped column.

    In planner, we need to map the Var nodes in MERGE actions to its corresponding TE in the main plan's TL. I used to do this under the assumption that all the TE are ordered by their attribute no (the value of filed "Var.varattno"). However, this is not the case when the table contain dropped attributes. The dropped attribute will take one attribute number but not appear in TL. 

     Now a new mapping algorithm is forged, which can avoid this bug. 

Please help me to review this new patch. Thank you!

PS:

In the new pgsql 9.1, I find that the junk attribute ctid is added twice, for UPDATE and DELETE commands. 

In planner, the function preprocess_targetlist() will invoke a sub function expand_targetlist() which will add missed TE for INSERT and UPDATE commands. And for UPDATE and DELETE, it will also create a TE of ctid (a junk attr) which is used in executor. This is the process in old pgsql versions. 

However, in pgsql 9.1, while the above is kept. A new function in rewriter, that is rewriteTargetListUD() does the same thing. So for a plain UPDATE/DELTE command, it will have two ctid junk attr in its final TL. 

Is there any particular reason for this duplicated ctid??

This will not cause much problem, normally. However, in MERGE command, the TL of MERGE actions should contain no junk attributes. So, I add blocking codes in these two parts, to avoid the change of TL of MERGE actions. I don't know whether this will cause any problem.

Regards,

Yours Boxan