Re: [HACKERS] Rules for 6.4 finished
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Rules for 6.4 finished |
Дата | |
Msg-id | 199808240125.VAA29135@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Rules for 6.4 finished (jwieck@debis.com (Jan Wieck)) |
Список | pgsql-hackers |
Patch applied. > Bruce, > > I'll send the patch itself directly to you. It's a bigger one > and I don't want to waste bandwidth on the list. Would you > please apply that one and forget the two others I posted > recently? The first rules patch (that is already applied) is > O.K. > > This is the final state of the rule system for 6.4 after the > patch is applied: > > Rewrite rules on relation level work fine now. > > Event qualifications on insert/update/delete rules work > fine now. > > I added the new keyword OLD to reference the CURRENT > tuple. CURRENT will be removed in 6.5. > > Update rules can reference NEW and OLD in the rule > qualification and the actions. > > Insert/update/delete rules on views can be established to > let them behave like real tables. > > For insert/update/delete rules multiple actions are > supported now. The actions can also be surrounded by > parantheses to make psql happy. Multiple actions are > required if update to a view requires updates to multiple > tables. > > Regular users are permitted to create/drop rules on > tables they have RULE permissions for > (DefineQueryRewrite() is now able to get around the > access restrictions on pg_rewrite). This enables view > creation for regular users too. This required an extra > boolean parameter to pg_parse_and_plan() that tells to > set skipAcl on all rangetable entries of the resulting > queries. There is a new function > pg_exec_query_acl_override() that could be used by > backend utilities to use this facility. > > All rule actions (not only views) inherit the permissions > of the event relations owner. Sample: User A creates > tables T1 and T2, creates rules that log > INSERT/UPDATE/DELETE on T1 in T2 (like in the regression > tests for rules I created) and grants ALL but RULE on T1 > to user B. User B can now fully access T1 and the > logging happens in T2. But user B cannot access T2 at > all, only the rule actions can. And due to missing RULE > permissions on T1, user B cannot disable logging. > > Rules on the attribute level are disabled (they don't > work properly and since regular users are now permitted > to create rules I decided to disable them). > > Rules on select must have exactly one action that is a > select (so select rules must be a view definition). > > UPDATE NEW/OLD rules are disabled (still broken, but > triggers can do it). > > There are two new system views (pg_rule and pg_view) that > show the definition of the rules or views so the db admin > can see what the users do. They use two new functions > pg_get_ruledef() and pg_get_viewdef() that are builtins. > > The functions pg_get_ruledef() and pg_get_viewdef() could > be used to implement rule and view support in pg_dump. > > PostgreSQL is now the only database system I know, that > has rewrite rules on the query level. All others (where I > found a rule statement at all) use stored database > procedures or the like (triggers as we call them) for > active rules (as some call them). > > Future of the rule system: > > The now disabled parts of the rule system (attribute > level, multiple actions on select and update new stuff) > require a complete new rewrite handler from scratch. The > old one is too badly wired up. > > After 6.4 I'll start to work on a new rewrite handler, > that fully supports the attribute level rules, multiple > actions on select and update new. This will be available > for 6.5 so we get full rewrite rule capabilities. > -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
В списке pgsql-hackers по дате отправления: