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

From: Boxuan Zhai <bxzhai2010(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: new patch of MERGE (merge_204) & a question about duplicated ctid
Date: 2010-12-04 13:27:52
Message-ID: AANLkTi=nfH4mW1c6JaRmKA2u4fyZRWr8OEr8HuSsBkw6@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear Greg,

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

Attachment Content-Type Size
merge204.tar.gz application/x-gzip 206 bytes

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2010-12-04 14:14:11 Re: Review: Extensions Patch
Previous Message Robert Haas 2010-12-04 11:48:19 Re: Patch to add a primary key using an existing index