> -----Original Message-----
> From: Jim Starkey [mailto:jas@...]
> Sent: Domingo 2 de Diciembre de 2001 13:59
>
> From an architectual view, I strongly recommend that Firebird revert
> to the original semantics PROVIDED a statisfactory mechanism can be
> found to preserve the existing behavior for existing systems that
> have had to accomodate the existing rules. Perhaps a keyword (say
> "preemptive") on triggers that intend to preempt the V6 rules, which
> would also preclude the trigger from being defined in an older
> version.

What about this?
I found the place in the compiler where it decides if the view is updatable
or not. If it's, the view isn't "expanded". If it's expanded, I understand
that the actions will be carried only by the triggers. Then:
- we revert to the old behavior
- rdb$relations.rdb$system_flags has only one flag defined, so we have
enough room. We provide here a flag for compatibility with v4-v6.
- when the relation block is created from system tables,
rel->rel_flags
will set a flag if the compatibility flag was found on rdb$relations
- when the compiler should decide what do to for action C, it doesn't expand
any view that has a before or after trigger for C, unless it has the
compatibility flag set and it's naturally updatable; C is here store, modify
or erase.
- we provide some extension to ALTER TABLE syntax to set the compatibility
mode, that in turn sets or resets the flag in rdb$relations.

This way, it's a global setting for all kinds of triggers in the view.

Speaking of views and semantics, providing before select triggers in tables
may be counter intuitive, but not in views, that have the right to fiddle
with the semantics of the operation.

C. (Flying too high this night with a couple of debugging sessions as to
figure out where the ground is.)
---------
Claudio Valderrama C.
Ingeniero en Informática - Consultor independiente
http://www.cvalde.com - http://www.firebirdSQL.org