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) #
