* Andres Freund (and...@anarazel.de) wrote:
> On 2015-10-05 08:01:00 -0400, Stephen Frost wrote:
> > Peter, all,
> > I had intended to address with policies what is addressed through
> > permissions with 7d8db3e, but the coverage for INSERT+RETURNING was only
> > done when ON CONFLICT was in use.
>
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I had intended to address with policies what is addressed through
> > permissions with 7d8db3e, but the coverage for INSERT+RETURNING was only
> > done when ON CONFLICT was in use.
>
> > I've fixed that by applying the SELECT poli
Stephen Frost writes:
> I had intended to address with policies what is addressed through
> permissions with 7d8db3e, but the coverage for INSERT+RETURNING was only
> done when ON CONFLICT was in use.
> I've fixed that by applying the SELECT policies as WCOs for both the
> INSERT and UPDATE RETUR
Andres,
On Monday, October 5, 2015, Andres Freund wrote:
> On 2015-10-05 08:01:00 -0400, Stephen Frost wrote:
> > Peter, all,
> > I had intended to address with policies what is addressed through
> > permissions with 7d8db3e, but the coverage for INSERT+RETURNING was only
> > done when ON CONFLI
On 2015-10-05 08:01:00 -0400, Stephen Frost wrote:
> Peter, all,
> I had intended to address with policies what is addressed through
> permissions with 7d8db3e, but the coverage for INSERT+RETURNING was only
> done when ON CONFLICT was in use.
>
> I've fixed that by applying the SELECT policies as
Peter, all,
* Peter Geoghegan (p...@heroku.com) wrote:
> I see now that commit 4f3b2a8883 changed things for UPDATE and DELETE
> statements, but not INSERT statements. I guess my unease is because
> that isn't entirely consistent with INSERT + RETURNING and the GRANT
> system. Logically, the only
> My proposal in this WIP patch is to make it a bit clearer that
> 'EXCLUDED' isn't a real relation. I played around with adding a
> different rtekind, but that's too heavy a hammer. What I instead did was
> to set relkind to composite - which seems to signal pretty well that
> we're not dealing wi
On Thu, Oct 1, 2015 at 5:12 PM, Andres Freund wrote:
> 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 e
On 2015-10-01 16:55:23 -0700, Peter Geoghegan wrote:
> On Thu, Oct 1, 2015 at 4:49 PM, Andres Freund 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
>
On Thu, Oct 1, 2015 at 4:49 PM, Andres Freund 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 matte
On Thu, Oct 1, 2015 at 4:26 PM, Peter Geoghegan wrote:
>> You can already see the effects of an INSERT modified by before triggers
>> via RETURNING. No?
>
> I'm not saying that I agree with the decision to not do anything
> special with RLS + RETURNING in general. I'm also not going to say
> that
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?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
On Thu, Oct 1, 2015 at 4:17 PM, Andres Freund wrote:
> On 2015-10-01 16:13:12 -0700, Peter Geoghegan wrote:
>> However, we're checking the excluded tuple (the might-be-inserted,
>> might-be-excluded tuple that reflects before row insert trigger
>> effects) with WCO_RLS_INSERT_CHECK, not WCO_RLS_UP
On Thu, Oct 1, 2015 at 3:53 AM, Andres Freund wrote:
>> I specifically remember discussing this with you off list (on IM,
>> roughly a couple of weeks prior to initial commit). I recommended that
>> we err towards a more restrictive behavior in the absence of any
>> strong principle pushing us one
On 2015-10-01 16:13:12 -0700, Peter Geoghegan wrote:
> However, we're checking the excluded tuple (the might-be-inserted,
> might-be-excluded tuple that reflects before row insert trigger
> effects) with WCO_RLS_INSERT_CHECK, not WCO_RLS_UPDATE_CHECK. The
> WCO_RLS_UPDATE_CHECK applies to the tuple
On Thu, Oct 1, 2015 at 3:42 AM, Andres Freund wrote:
> Yes, that what I think as well. At this point we'll already have
> executed insert rls stuff on the EXCLUDED tuple:
> /*
> * Check any RLS INSERT WITH CHECK policies
> *
> * E
On 2015-09-29 11:52:14 -0700, Peter Geoghegan wrote:
> On Tue, Sep 29, 2015 at 8:24 AM, Andres Freund wrote:
> > So, took a bit longer than "tomorrow. I fought for a long while with a
> > mysterious issue, which turned out to be separate bug: The excluded
> > relation was affected by row level sec
On 2015-09-29 15:49:28 -0400, Stephen Frost wrote:
> From Andres' reply, it looks like this is about the EXCLUDED pseudo
> relation which comes from the INSERT'd values themselves
Right.
> in which case, I tend to agree with his assessment that it doesn't
> make sense for those to be subject to R
* Peter Geoghegan (p...@heroku.com) wrote:
> On Tue, Sep 29, 2015 at 8:24 AM, Andres Freund wrote:
> > So, took a bit longer than "tomorrow. I fought for a long while with a
> > mysterious issue, which turned out to be separate bug: The excluded
> > relation was affected by row level security poli
On September 29, 2015 8:52:14 PM GMT+02:00, Peter Geoghegan
wrote:
>On Tue, Sep 29, 2015 at 8:24 AM, Andres Freund
>wrote:
>> So, took a bit longer than "tomorrow. I fought for a long while with
>a
>> mysterious issue, which turned out to be separate bug: The excluded
>> relation was affected by
On Tue, Sep 29, 2015 at 8:24 AM, Andres Freund wrote:
> So, took a bit longer than "tomorrow. I fought for a long while with a
> mysterious issue, which turned out to be separate bug: The excluded
> relation was affected by row level security policies, which doesn't make
> sense.
Why? You certain
On 2015-09-24 17:25:21 +0200, Andres Freund wrote:
> Stuff I want to fix by tomorrow:
> * Whole row var references to exclude
> * wrong offsets for columns after dropped ones
> * INSTEAD DO UPDATE for tables with oids
>
> Do you know of anything else?
So, took a bit longer than "tomorrow. I fought
On Thu, Sep 24, 2015 at 8:25 AM, Andres Freund wrote:
> Stuff I want to fix by tomorrow:
> * Whole row var references to exclude
> * wrong offsets for columns after dropped ones
> * INSTEAD DO UPDATE for tables with oids
>
> Do you know of anything else?
You said something in Dallas about the tes
On 2015-09-19 18:40:14 -0700, Peter Geoghegan wrote:
> > An actually trivial, although not all that pretty, fix is to simply
> > accept wholerow references in fix_join_expr_mutator(), even if not in
> > the targetlist. As far as I can see the problem right now really can
> > only be hit for whole r
On Sat, Sep 19, 2015 at 5:11 PM, Andres Freund wrote:
> Peter's patch upthread fixes this by pulling expressions from
> onConflictSet/Where into the targetlist. I disliked this - much less
> than initially - a bit because that seems a bit crufty given that we're
> not actually getting data from a
Hi,
To recap for other readers: There's a problem with ON CONFLICT when the
SET or ON CONFLICT ... WHERE clause references excluded.* (i.e. as a
whole row var). The problem is that setrefs.c in
fix_join_expr_mutator() currently won't find a matching entry in the
indexed tlist and thus error out w
26 matches
Mail list logo
