At 01:27 AM 12/3/01 -0400, Claudio Valderrama C. wrote:

>
>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.
>

Sounds good to me. Re-establishes same semantics while providing
for backwards compatibility.

>
>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.
>

Been there, didn't do that. Tried and found a better way. But keep
looking. Maybe there's a nugget there.

Jim Starkey