<div dir="ltr"><div class="gmail_extra"><br /><div class="gmail_quote">On Wed, Nov 6, 2013 at 6:38 AM, Craig Ringer
<spandir="ltr"><<a href="mailto:craig@2ndquadrant.com" target="_blank">craig@2ndquadrant.com</a>></span>
wrote:<br/><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div
style="overflow:hidden">That'sthe approach I've been considering. There are a few wrinkles with<br /> it, though:<br
/><br/> (a) Updatable views are implemented in the rewriter, not the planner.<br /> The rewriter is not re-run when
plansare invalidated or when the<br /> session authorization changes, etc. This means that we can't simply omit<br />
theRLS predicate for superuser because the same rewritten parse tree<br /> might get used for both superuser and
non-superuserqueries.<br /></div></blockquote></div><br /></div><div class="gmail_extra">Incidentally I still feel this
isat root the problem with updateable views in general. I know it's a bit off to be tossing in concerns from the peanut
gallerywhen I'm not actually offering to work on it and others are having putting in serious efforts in this area and
havingsome success. So take this for what it's worth...<br /><br /></div><div class="gmail_extra">I think the right
approachfor updateable views would be to support a syntax like this in the planner:<br /><br /></div><div
class="gmail_extra">UPDATE(select * from tab1,tab2 ...) WHERE <a href="http://tab1.id" target="_blank">tab1.id</a> = ..
SET...<br /><br /></div><div class="gmail_extra">Then updateable views would just rewrite the query mechanically the
wayregular views work by substituting the view definition in place of the view name. Since all the work would be done
inthe planner it would have access to the same kinds of information that regular join planning etc have.<br
/></div><divclass="gmail_extra"><br /></div><div class="gmail_extra">I'm not sure if this solves all the problems with
RLSbut it would solve the concern about plan invalidations and I think it would make it simpler to reason about
securityrules that are otherwise happening at plan time.<br clear="all" /></div><div class="gmail_extra"><br />-- <br
/>greg<br/></div></div>
