Comments inserted below.

Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com


"Jim Starkey" <jas@...> wrote in message

> Jason, it would easier to understand your proposals if you were to
> include the problem you are addressing and the actual semantics of
> your proposed change. Tossing a piece of syntax over the wall doesn't
> quite cut it.

Please read the prior posts to know the problem at hand.
My "tossed in syntax" was to illustrate my points, which could stand on
their own as well.

> >> It would break most existing applications and basic SQL standard
> >conformance.
> >
> >Not entirely. Any trigger on a view would make it updatable for that

action.

> >All existing VIEWs defined in a database would have the default triggers
> >performing the update. Thus, they would continue to be updatable due to

the

> >existence of the triggers already there. So, no applications would be
> >broken. It would only be a problem when they recreate the view and forget
> >the new token to indicate that they want the default triggers for

updating

> >to be assigned.
> >
>
> Ugh. The history of system generated triggers in Interbase is not
> pleasant. There are a whole series of problems, including:
>
> 1. Name space management
> 2. Backwards compatibility
> 3. System or user ownership
> 4. Namespace management
> 5. Future upgradability
>
> How would the system know when to create a magic default trigger? If
> it's done at view creation, it will screw up an existing trigger waiting
> to be created in a backup file. Do you make a magic rule that says a
> trigger definition that overlaps the name of magic default trigger
> supercedes that trigger?
>
> Does a magic default trigger go away when the view is deleted? If
> so, how do you update the view definition. If not, how is does
> automatic view update work when the view definition is changed?
>
> Ugh.

You have projected problems which are simply a reality of the situation.

What I am suggesting is to put existing behaviors under more explicit
control, and that is really the extent of it. I'm not suggesting to
"introduce" system triggers where there aren't already ones there. This
skirts us around all the issues you bring up here.

If the default view updates are not carried out in system triggers then
substitute what I said with the existance of the system mechanism which
carries out the default view updating (which is ambiguous as far as I'm
concerned). Mainly, I just want a way to turn them off so they don't get in
the way. <g>

> Jim Starkey