Another issue that I see is that there is only one resultRelation between the INSERT and UPDATE. That means that without some additional special measure, both UPDATE and INSERT "WITH CHECK ( ... ) " options are applied regardless of whether the INSERT path was taken, or the UPDATE path. Maybe that's actually sensible (note that even this doesn't happen right now, since the auxiliary UPDATE is currently minimally processed by the rewriter). What do people think about that? It seems like it might be less surprising to have that fail earlier when there are separate policies for INSERT and UPDATE -- for UPSERT, all policies are applied regardless of which path is taken.
The task of making the security qual enforced like a check option before we go to update a locked row (at the start of the UPDATE path, for any UPDATE policy with a USING security qual) looks complicated. I'd appreciate a little help on the implementation details. Apparently Oracle does not offer "fine-grained access control" with MERGE, which I believe means they just don't support this kind of thing at all. Obviously I'd rather avoid that here, but the correct semantics are not obvious. ON CONFLICT UPDATE could almost justify making CREATE POLICY FOR INSERT accept a USING expression, since that's really where the row to UPDATE comes from. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
