(2010/08/18 21:52), Stephen Frost wrote: > * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: >> If rte->requiredPerms would not be cleared, the user of the hook will >> be able to check access rights on the child tables, as they like. > > This would only be the case for those children which are being touched > in the current query, which would depend on what conditionals are > applied, what the current setting of check_constraints is, and possibly > other factors. I do *not* like this approach. > Indeed, the planner might omit scan on the children which are not obviously referenced, but I'm not certain whether its RangeTblEntry would be also removed from the PlannedStmt->rtable, or not.
>> How about an idea to add a new flag in RangeTblEntry which shows where >> the RangeTblEntry came from, instead of clearing requiredPerms? >> If the flag is true, I think ExecCheckRTEPerms() can simply skip checks >> on the child tables. > > How about the external module just checks if the current object being > queried has parents, and if so, goes and checks the > labels/permissions/etc on those children? That way the query either > always fails or never fails for a given caller, rather than sometimes > working and sometimes not depending on the query. > Hmm, this idea may be feasible. The RangeTblEntry->inh flag of the parent will give us a hint whether we also should check labels on its children. Thanks, -- KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
