merge command - GSoC progress

---------- Forwarded message ----------
From: Boxuan Zhai <bxzhai2010(at)gmail(dot)com>
Date: 2010/7/26
Subject: Re: GSoC progress
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>

Hi,

I have get a edition that the merge command can run. It accept the standard
merge command and can do UPDATE, INSERT and DELETE actions now. But we
cannot put additional qualification for actions. There are some bugs when we
try to evaluate the quals which make the system quit. I will fix it soon.

The merge actions are packed in ModifyTable nodes now. This can benefit the
coding if we want to implement MERGE ... RETURNING ...

Please find the patch file in attachment.

2010/7/24 Robert Haas <robertmhaas(at)gmail(dot)com>

On Fri, Jul 23, 2010 at 12:21 PM, Boxuan Zhai <bxzhai2010(at)gmail(dot)com> wrote:
> > I my current implementation, the overall merge command plan is still a
> > single ModifyTable node. And the main query of merge command is in the
> field
> > of ModifyTable.plans. I add a new "List * mergeActPstates" field in the
> > structure of ModifyTableState. When apply the ExecInitModifyTable()
> function
> > on a ModifyTable node of a merge command, the function will do an extra
> work
> > to init all the merge actions and put the result into the
> > list of mergeActPstates. (in previous design, I put the list in
> > PlannedStmt, but that makes the code a little bit ugly).
>
> Hmm, that might work.
>
> > I now put all merge-command-related functions in the file of
> > nodeModifyTable.c. and I have fixed something that I missed in the init
> > process for merge command, such as set the junkfiler attribute for ctid.
> > However, I still cannot run ExecProject over the tuple slot returned
> by main
> > query.
> >
> > In fact, I am not sure how ExecProject () works exactly. It totally
> depends
> > on the correctness of the input ProjectionInfo, in which we have a
> > "ExprContext *pi_exprContext" parameter. The expression context should
> > contains all the tuple slot needed for the projection. I
> > init ProjectionInfo correctly, but the expression context is empty when
> > initialized. Could you tell me WHEN does the system fill the tuple slots
> > (the ecxt_scantuple, ecxt_innertuple, ecxt_outertuple) in the expression
> > context of the ProjectionInfo structure?
>
> I'm not real familiar with this part of the code; that would be a good
> question to ask on pgsql-hackers. But I believe the answer is that
> the individual node types initialize the expression context at the
> appropriate time. For example, if you grep for ecxt_innertuple,
> you'll find that it's set in the hash, merge, and nestloop nodes;
> whereas the scan tuple is set by the scan, bitmap heap, and index scan
> nodes.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise Postgres Company
>