INSERT ... ON CONFLICT UPDATE and RLS

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>
Subject: INSERT ... ON CONFLICT UPDATE and RLS
Date: 2015-01-05 17:54:02
Message-ID: CAM3SWZRFwmmk4ZctRb5V_V4nqgZ2wZ7B=HJeArjoDPXv_ModXA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

The patch that implements INSERT ... ON CONFLICT UPDATE has support
and tests for per-column privileges (which are not relevant to the
IGNORE variant, AFAICT). However, RLS support is another thing
entirely. It has not been properly thought out, and unlike per-column
privileges requires careful consideration, as the correct behavior
isn't obvious.

I've documented the current problems with RLS here:

https://wiki.postgresql.org/wiki/UPSERT#RLS

It's not clear whether or not the auxiliary UPDATE within an INSERT...
ON CONFLICT UPDATE statement should have security quals appended.
Stephen seemed to think that that might not be the best solution [1].
I am not sure. I'd like to learn what other people think.

What is the best way of integrating RLS with ON CONFLICT UPDATE? What
behavior is most consistent with the guarantees of RLS? In particular,
should the implementation append security quals to the auxiliary
UPDATE, or fail sooner?

[1] http://www.postgresql.org/message-id/20141121205926.GK28859@tamriel.snowman.net
--
Peter Geoghegan

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-01-05 17:54:41 Re: Re: Patch to add functionality to specify ORDER BY in CREATE FUNCTION for SRFs
Previous Message Heikki Linnakangas 2015-01-05 17:38:43 Re: pg_rewind in contrib