Craig Ringer <craig@2ndquadrant.com> writes:
> On 11/12/2013 05:40 AM, Robert Haas wrote:
>> I haven't studied this issue well enough to know what's really needed
>> here, but Dean Rasheed's approach sounded like a promising tack to me.
> I've been looking further into adding update support for security
> barrier views and after reading the code for UPDATE ... FROM I don't
> understand why there was any need to add separate targetRelation and
> sourceRelation plan attributes.
I've not read the prior patch, but that sounds a bit bogus to me too.
> [ lots o details snipped ]
> Totally crazy? Or workable? I'm extremely new to the planner, so I know
> this might be unworkable, and would value advice.
The main omission I notice in your sketch is that the join tree that is
the source of tuples has to produce both the ctid of the row to be
updated, and values for *all* the columns of the target relation.
So for any column that's not updated explicitly in the UPDATE command,
we have to fetch the old value. IOW, if we have a table with columns
x,y,z, and the original command is
UPDATE ... SET y = something FROM ...
then we effectively transform that to
UPDATE ... SET x = x, y = something, z = z FROM ...
and so we have to pull old values of x and z, as well as whatever
we need to calculate the "something". I don't think this invalidates
anything you said, but it did seem to be missing from the sketch
(in particular, we need those old values independently of whether
there's any RETURNING clause, because they have to be stored back
into the freshly-formed updated tuple).
What I've not seen explained here is what is different between updating a
security barrier view and the already-implemented logic for updating
a plain view?
regards, tom lane
