At 01:05 AM 12/4/01 +0100, Ivan Prenosil wrote:

>
>Jim,
>Just to be sure I understand you right:
>
>CREATE TABLE tab (...);
>
>CREATE VIEW v AS
> SELECT * FROM tab;
>
>CREATE TRIGGER tr FOR v BEFORE INSERT ...;
>
>Are you saying that this command
> INSERT INTO v (...) VALUES (123);
>should fire trigger tr, but should _not_ insert 123 directly into table tab ?
>

That is correct. Any pre-insert trigger was presumed to override
any automatic view insert semantics. The relationship between
views and pre-insert (update, delete) triggers was consistent without
regard to whether the view was considered updatable.

Among the many problems this avoided was the definition of an
updateable view. At the time, the SQL committee didn't have an
opinion on whether views were updateable or not. The various
other authorities were in violent disagreement on the subject.
The idea of tying database semantics to a future determination
by a rather arbitrarily selected committee didn't seem like a
wise course of action. Just think about the manual: "the effect
of an insert operation into a view is fully supported but subject
to change by a bunch of prima donas yet to be appointed. Good
luck, Mr. Programmer."

If a trigger is deemed to establish the semantics of a view update,
it should establish the update semantics without regard to what
a committee has determined to be the acceptable state of the art.

Jim Starkey