On 02/04/2014 02:43 PM, Craig Ringer wrote: > On 01/30/2014 04:05 PM, Craig Ringer wrote: >> On 01/30/2014 01:25 PM, Craig Ringer wrote: >>> On 01/29/2014 09:47 PM, Craig Ringer wrote: >>>> https://github.com/ringerc/postgres/compare/rls-9.4-upd-sb-views >>>> >>>> i.e. https://github.com/ringerc/postgres.git , >>>> branch rls-9.4-upd-sb-views >>>> >>>> (subject to rebasing) or the non-rebased tag rls-9.4-upd-sb-views-v2 >>> >>> Pushed an update to the branch. New update tagged >>> rls-9.4-upd-sb-views-v3 . Fixes an issue with rowmarking that stems from >>> the underlying updatable s.b. views patch. >>> >>> Other tests continue to fail, this isn't ready yet. >> >> Specifically: > >> - row-security rule recursion detection isn't solved yet, it just >> overflows the stack. > > This is now fixed in the newly tagged rls-9.4-upd-sb-views-v4 in > g...@github.com:ringerc/postgres.git .
Based on Tom's objections, another approach is presented in rls-9.4-upd-sb-views-v5 on g...@github.com:ringerc/postgres.git . The Query node is used to record the recursive expansion parent list instead, and copying is avoided. However, I've separately tracked down the cause of the test failures like: ERROR: could not open file "base/16384/30135": No such file or directory This occurs where a row-security qual is declared to use a view. Row-security quals get stored without rewriting (which is necessary, see below). The qual is injected into securityQuals and expanded, but *not rewritten*. So the executor sees an unexpected view in the tree. Because a view RTE has its relid field set to the view's oid, this doesn't get picked up until we try to actually scan the view relation in the executor. (I'd like to add Asserts to make the executor fail a bit more informatively when you try to scan a view, but that's separate.) So, that's clearly broken. There are really two possible solutions: 1. Try (again) to do row-security in the rewriter. This was previously impossible because of the definition of row-security behaviour around inheritance, but with the simplified inheritance model now proposed I think it's possible. 2. Invoke RewriteQuery from within expand_security_quals, rewriting the query after security qual expansion. This is only needed for row-security; for updatable s.b. views rewriting has happened with recursion into securityQuals during the original rewrite pass. I suspect that (2) will result in a resounding "yuck". So I have to see if I can now turn around *again* and plug row-security into the rewriter after all. That's a pretty frustrating thing to discover in mid-late CF4. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers