On 5/14/14 6:41 AM, Amit Kapila wrote:
IIUC, the way new design will work is that for new tuple we will now
get tableoid+TID, modified column values as an input (for inheritance
tables we will get this for all child tables as well) for ModifyTable
and get old tuple (which in current case will be provided by MergeAppend
or in general by some scan node) from some node beneath the
ModifyTable. It then matches the tableoid from old tuple with appropriate
tableoid incase of child tables and then form the new tuple for that
tableoid using old tuple and modified column values.
Having now read the discussion upthread a bit more carefully, I think
one of us is confused. AIUI, what was suggested was that the plan nodes
below the ModifyTable node would only give you back the modified
columns, the tableoid and the TID of the tuple, and no "old values" at
all. This might be a reasonable approach, but I haven't given it that
much thought yet.
In this case can we safely assume that we will always get tableoid from
old tuple, ideally it should be there but just not sure
It has to be there or otherwise the scheme won't work. Is there a
specific case you're worried about?
and another minor
point is won't we get TID from old tuple (tuple we get from node beneath
ModifyTable), what's the need to pass for new tuple?
I don't understand this part, could you rephrase?
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: