From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ON CONFLICT issues around whole row vars, |
Date: | 2015-10-02 00:12:32 |
Message-ID: | 20151002001232.GB32326@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2015-10-02 00:41:25 | Re: ON CONFLICT issues around whole row vars, |
Previous Message | Peter Geoghegan | 2015-10-01 23:55:23 | Re: ON CONFLICT issues around whole row vars, |