a new problem in MERGE

Dear Greg,

How are you?

As we talked last week, there is a bug about the "origslot" field
assertion.

TRAP: FailedAssertion("!(epqstate->origslot != ((void *)0))", File:
"execMain.c", Line: 1732)

I checked my codes and found the reason of this problem. In the original
process of "ExecModifyTable()" function, there is a line of code
"EvalPlanQualSetSlot(&node->mt_epqstate,
planSlot);"

It is specially used to init the epqstate->origslot field with the tuple
slot returned by the underlying plan. However, in our implementation of
MERGE, this part is missed in "ExecMerge()" function.

At the beginning, I just tried to form a new slot in "ExecMerge()" and use
it as the epqstate->origslot for the merge actions' execution functions.
This part is simple.

But, during this process, I found a more serious problem: our MERGE
currently does not support the use of system attributes in the action
conditions and target lists.

For example, if we raise queries like the following, there will pops some
ERROR message.

(table target has oid attribute)
MERGE INTO target t USING source s ON t.id = s.id
WHEN MATCHED AND* t.oid >100000* THEN update SET val = t.val + s.add;

or

MERGE INTO target t USING source s ON t.id = s.id
WHEN MATCHED AND* t.xmin = 1000* THEN update SET val = t.val + s.add;

The reason for the above problem is the missing of system attribute in the
result slot returned by the main plan of MERGE.

In our implementation, the Main Pan of MERGE just generate a tuple slot
contain all the direct vars from source table and target table. The
expressions in MERGE action conditions and target lists are then calculated
based on the result slot of main plan.

Currently, all the system attributes (except the ctid of target table) are
not included in main plan. So, the evaluation of action condition and target
entries will fail if they involve some system attributes.

If we want to solve this problem, we need to extend the target list of main
plan before execution (in analyzer or planner), make sure it contains all
the attributes appeared in any of the MERGE actions. This may lead to
adjustments to many part of the process of MERGE. For example, within the
planner, I created a function specially for mapping the Var nodes in actions
to attributes in the result slot. This function should be rewritten for this
new case.

I have plan to fix the above two bugs together. (in fact, I have already
started coding in merge_v202 edition). My question is how should I make my
update be consistent with yours. Is it possible for you to give me an
edition that I can work on?

Thanks!

Yours Boxuan