Re: CREATE POLICY and RETURNING - Mailing list pgsql-hackers

From Zhaomo Yang
Subject Re: CREATE POLICY and RETURNING
Date
Msg-id 1439195978836-5861550.post@n5.nabble.com
Whole thread Raw
In response to Re: CREATE POLICY and RETURNING  (Stephen Frost <sfrost@snowman.net>)
Responses Re: CREATE POLICY and RETURNING  (Zhaomo Yang <zmpgzm@gmail.com>)
Re: CREATE POLICY and RETURNING  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Hi,

This thread has a pretty thorough discussion of pros and cons of applying
SELECT policy to other commands. Besides what have been mentioned, I think
there is another potential pro: we can enable references to pseudorelations
OLD and NEW in predicates. Now, for UPDATE, the references to the target
table in USING clause are actually references to OLD and the references in
WITH CHECK clause are references to NEW. Logically now USING and WITH CHECK
are combined by AND, so we cannot have predicates like
         foo(NEW) > 1 OR bar(OLD) > 1   (combine predicates referencing OLD
and NEW by an operation other than AND)         NEW.id <> OLD.id        (reference both in the same expression)

If we apply SELECT policy to other commands, we only need one predicate for
INSERT/UPDATE/DELETE. That predicate can reference to OLD and NEW, just like
predicates for triggers and rules. For UPDATE and DELETE, the predicate of
SELECT will be applied first (when the target table is scanned) to ensure no
information leakage and their own predicate will be applied later. This
doesn't change much for INSERT and DELETE, but it gives users more
flexibility when they set predicates for UPDATE.

Thanks,
Zhaomo



--
View this message in context: http://postgresql.nabble.com/CREATE-POLICY-and-RETURNING-tp5823192p5861550.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: checkpointer continuous flushing
Next
From: Zhaomo Yang
Date:
Subject: Re: CREATE POLICY and RETURNING