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

From Stephen Frost
Subject Re: ON CONFLICT issues around whole row vars,
Date
Msg-id 20151005120059.GH3685@tamriel.snowman.net
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,  (Andres Freund <andres@anarazel.de>)
Re: ON CONFLICT issues around whole row vars,  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Peter, all,

* Peter Geoghegan (pg@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 possible justification for our long
> standing INSERT and RETURNING behavior with GRANT (the fact that it
> requires SELECT privilege for rows returned, just like UPDATE and
> DELETE) is that before row insert triggers could do something secret
> (e.g. they could be security definer). It doesn't seem to be too much
> of a stretch to suppose the same should apply with RLS.

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 RETURNING cases.  This matches the permissions system,
where we require SELECT rights on the table for an INSERT RETURNING
query.

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Rename withCheckOptions to insertedCheckClauses
Next
From: Shay Rojansky
Date:
Subject: Re: Odd query execution behavior with extended protocol