Re: [HACKERS] Delaying insertion of default values

Vadim wrote:

> ALTER TABLE could (or should?) re-compile table' rules...

    Rules should be recompilable for various reasons. DROP/CREATE
    of objects (relations, functions etc.)  referenced  in  rules
    changes their OID and needs recompilation too.

    Thus  we  need  to  store  the original rule text and a cross
    reference listing all the objects used in the rules  actions.
    That's two new system catalogs for me.

    Another  problem  with  rules coming up every so often is the
    rule plan string too big error. I'm actually  thinking  about
    arbitrary tuple sizes and will open another discussion thread
    on that, but I'm not sure how far we'll get this for v6.6 and
    if  the  solution  would  be  good  enough  to  handle system
    catalogs and syscache entries as well. To get  rules  out  of
    the  way  here  and beeing free to add this technique to user
    tables only I'll go ahead then and implement  rule  qual  and
    action splitting handled by the rule system itself anyway.

> > rule mechanism.  Unless I hear objections, I will do that while I am
> > cleaning up INSERT processing for the INSERT ... SELECT ... GROUP BY bug.
>
> No objections -:).

    This  would  be  obsolete when having the above recompilation
    implemented.  I'll add a support function that takes  an  OID
    which      should      be      called     at     any     DROP
    TABLE/VIEW/FUNCTION/OPERATOR  etc.  which  will  cause   rule
    recompilation on the next usage of the relation.


Jan

--

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