Re: ON CONFLICT issues around whole row vars, - Mailing list pgsql-hackers

From Andres Freund
Subject Re: ON CONFLICT issues around whole row vars,
Date
Msg-id 20151002001232.GB32326@awork2.anarazel.de
Whole thread Raw
In response to Re: ON CONFLICT issues around whole row vars,  (Peter Geoghegan <pg@heroku.com>)
Responses Re: ON CONFLICT issues around whole row vars,  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
On 2015-10-01 16:55:23 -0700, Peter Geoghegan wrote:
> On Thu, Oct 1, 2015 at 4:49 PM, Andres Freund <andres@anarazel.de> wrote:
> > On 2015-10-01 16:26:07 -0700, Peter Geoghegan wrote:
> >> FWIW, I think that this technically wasn't a bug
> >
> > Meh. In which scenario would do a policy applied to EXCLUDED actually
> > anything reasonable?
> 
> I agree that it's very unlikely to matter. Consistency is something
> that is generally valued, though.

I don't think you get my gist.

I'm can't see how the current code can do anything sensible at all. What
do you think is going to be the effect of an excluded row that doesn't
meet security quals? Even if it worked in the sense that the correct
data were accessed and every - which I doubt is completely the case as
things stands given there's no actual scan node and stuff - you'd still
have EXCLUDED.* being used in the projection for the new version of the
tuple.

As far as I can see the only correct thing you could do in that
situation is error out.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: ON CONFLICT issues around whole row vars,
Next
From: Peter Geoghegan
Date:
Subject: Re: ON CONFLICT issues around whole row vars,