Rules for 6.4 finished

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.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #