The current code just reads:
/*
* For now, we also don't support security-barrier views, because of the
* difficulty of keeping upper-level qual expressions away from
* lower-level data. This might get relaxed in future.
*/
if (RelationIsSecurityView(view))
return gettext_noop("Security-barrier views are not automatically
updatable.");
which doesn't tell me tons. Is it the same problem RLS faces where you
can't just append the view predicate to the update predicate because you
may leak information if the update predicate gets evaluated before the
view predicate?
RLS attempts to solve that by wrapping the range table entry for the
relation in a subquery over the original table qualified with the rls
predicate, forcing its evaluation before the outer predicate of the
user-supplied query. That approach seems to be unpopular, but how much
of that is about the implementation by doing rewriting in the planner
its self, and how much is objection to the principle?
If updateable views supported security barriers it'd really help reduce
the amount of complex planner messing-around in the RLS patch, so this
is something I'm quite interested in tacling if anyone has a few
pointers on where to look to start with.
It wouldn't be total solution to RLS, as we'd still have the issue of
the rewriter not getting re-run on plan invalidation and re-planning,
which causes issues if the RLS clause was omitted first time and
shouldn't be this time or vice versa. We'd need to be able to store the
pre-rewrite parse tree and re-run the rewriter for plans where one or
more relations were flagged as having RLS.
>From what Kohei KaiGai was saying it sounds like we'd also need to
re-define how RLS and inheritance interacted, so a parent's RLS
predicate applies to all its children, as one of the reasons he had to
do it in the optimizer/planner was because of difficulties handling
totally independent RLS expressions for child and parent tables at the
rewriter level.
Might this be a more palatable way forward than the fiddling with Vars
and doing query rewriting inside the optimizer that the current RLS
patch does?
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
