Ivan,

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

> Are you saying that _each_ view should be read-only by default,
> unless you explicitly allow default processing ?
> 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.

I much prefer to specify in the positive the default auto-update triggers be
defined because then if for any reason they can't be the developer is
informed with an error message. This way people will know what view SQL can
be auto updatable and what isn't. To turn it the other way around, to
specify the negative case doesn't afford complete control of the situation.
There would still be ambiguity because the line between what is updateable
and what isn't probably isn't clear to the average developer-user.

It is also important to me that individual control over the insert, update
and delete operations be afforded.

In short, the developer should be in complete control over when the default
triggers are assigned and their effectiveness. There should be no potential
ambiguity allowed either. The way I am suggesting is the only way I can
think of to make it clearly that way.

Another thing that could be considered is if the FOR clause it omitted
entirely have it behave just exactly as it does now. Then, include the
SELECT token in the FOR clause if that is all you want done.

CREATE VIEW FOR SELECT AS BEGIN ...

I think the fact that any trigger placed on a VIEW by the developer would
act as an overriding condition to allow a VIEW to be updateable for that
action should be clearly made. There is no point of a trigger for an
operation that will never happen.

In short, if no FOR clause is defined the current behavior can continue and
that is fine with me. But, to get the extra control we need we should use
the FOR clause and explicitly tell which operations we want, or none if
that's the case.

In fact, what we can do is snitch the tokens used in permissions.

CREATE VIEW
FOR SELECT, INSERT, UPDATE, DELETE
AS
BEGIN

This could be substituted with.

CREATE VIEW
FOR ALL
AS
BEGIN


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