Re: [HACKERS] Rules for 6.4 finished - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] Rules for 6.4 finished
Date
Msg-id 199808240125.VAA29135@candle.pha.pa.us
Whole thread Raw
In response to Rules for 6.4 finished  (jwieck@debis.com (Jan Wieck))
List 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 by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] What I'm working on
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] What I'm working on