On 8 October 2012 15:57, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: > The attached patch is a refreshed version towards the latest master branch, > to fix up patch conflicts. > Here is no other difference from the previous revision. > > Thanks, >
I had another look at this over the weekend and I found couple of additional problems (test cases attached): 1). It is possible to define a RLS qual that refers back to the table that it's defined on, in such a way that causes infinite recursion in the planner, giving "ERROR: stack depth limit exceeded". I think it would be preferable to trap this and report a more meaningful error back to the user, along similar lines to a self-referencing view. 2). In other cases it is possible to define a RLS qual that refers to another table with a RLS qual in such a way that the second table's RLS qual is not checked, thus allowing a user to bypass the security check. 3). If a RLS qual refers to a view it errors, since the RLS quals are added after rule expansion, and so the view is not rewritten. To me this suggests that perhaps the expansion of RLS quals should be done in the rewriter. I've not thought that through in any detail, but ISTM that a RIR rule could add a table with a RLS qual, and a RLS qual could add a relation with a RIR rule that needs expanding, and so the 2 need to be processed together. This could also make use of the existing recursion-checking code in the rewriter. Regards, Dean
test.sql
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
