At 10:11 AM 12/3/01 -0700, Jason Wharton wrote:

>
>> I am not sure I understand you right.
>
>You just haven't thought through what I am suggesting far enough because is
>all what I have suggested would do is what you suggested.
>

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.

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



Jim Starkey