Jim, Claudio,

Perhaps I was not clear enough. I do agree with most things you wrote.
The ability to change semantics of view by suppressing its default
behaviour and supplying new code in trigger is great, is superduper, ....

The only thing I do not agree with is the way how to "activate" such feature.

> The alternative to this mess is a simple and consistent rule:
> Any before update trigger overrides automatic view update.

I do agree that this rule _is_ simple and consistent,
but I would still prefer _explicit_ control,
rather than this "side effect" type control.

====

IMO the problems start with SQL92 itself (as Jim already said).
SQL92 knows "clearly updatable" views, "clearly read-only" views,
and then something between. E.g.
CREATE VIEW v(a,b) AS SELECT x,1 FROM tab;
is read-only in Entry level SQL, but can be updatable in higher levels.
Just sentence in db documentation "we now fully support Intermediate
level instead of Entry level" is enough to change behaviour
and thus break lot of applications. It is _BAD_.
Should not we better add the possibility to explicitly declare
intended type of view ? Something like
CREATE VIEW v(a,b) READ ONLY AS SELECT x,1 FROM tab;
or
CREATE VIEW v(a,b) FOR UPDATE AS SELECT x,1 FROM tab;

This would solve ambiguity in SQL92 itself, and at the same time
it would make unnecessary to introduce another rules, like
"Any before update trigger overrides automatic view update."

====
Here is another problem with "trigger overrides automatic view update" approach:
how would you solve problem with view:

CREATE VIEW v(a) AS
SELECT x
FROM tab
WHERE x>0
WITH CHECK OPTION;

IF the trigger on this view overrides automatic view update,
than the clause "WHERE x>0 WITH CHECK OPTION" will not work either !!
Pretty confusing to look at such metadata !

Or do you want to not allow triggers on views with CHECK OPTION at all ?

====

Ivan
http://www.volny.cz/iprenosil/interbase