>
> > > Depends on WHEN 6.6 is planned to go into feature-freeze.
> >
> > Well, I believe that we have at least 3 months before 1st beta.
> > We need in DIRTY READs for RI and I'll implement them.
> > If you'll not be able to do RI itself then we might
> > change refint.c to use DIRTY READs and so avoid LOCK TABLE
> > on application level (i.e. restore pre-6.5 refint.c using).
>
> Yikes. Three months. That puts us at release in mid-January.
Three months - sounds fine. I just posted another few ideas
on the issue. After rereading it, I'm sure now that doing RI
with the rulesystem would open a horrible can of worms.
Especially in the case a trigger procedure is using a query
which in turn triggers a deferred rule.
Each trigger invocation (maybe for thousands of rows) will
execute it's own queries, resulting in a separate parsetree
for the deferred actions. Where to hold them? Parsetrees can
be huge!
I'm sure now that remembering the CTID's of the tuples that
must get reread to fire the trigger is the smaller problem.
I need a little break in my current project - thus I'll take
a look at it NOW!
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) #