I'm with you in principle.

If there wasn't any implementation to worry about being compatible with, I
would prefer that views be read-only unless one of two conditions were met.

#1) I explicitly asked the view to attempt to automatically put in place
some system mechanism (probably a system trigger) to make my view updateable
for me, and that it would fail to do so in the cases that it couldn't, like
if there were a JOIN in my statement.

#2) I subsequently put a trigger of my own on it. Why else would I put a
trigger there if I weren't intending on the relevant action to take place on
the view.

In the case where these two cases may overlap, one should expect that the
system action would still take place and there would be good reason to
expect it to do so because you asked it to, therefore, the trigger you added
yourself wasn't there to carry out the implementation of the operation but
to feed an external data stream or perform validations, or whatever as you
would normally do with raw tables.

The problem we have is there is an existing implementation which does things
not explicitly asked for in a manner to the beginner that would seem
ambiguous. One would eventually have the question, "when does and when
doesn't IB automatically make a trigger updateable?". The only way people
get consistent behavior is to fake a JOIN and control it themselves.

That is why I proposed a compromise and hurled some syntax over the wall,
hoping people would derive a clearer understanding of my suggestions, that I
though were sufficiently explained without them.

What I am suggesting comes nowhere near the morass of problems Jim tried to
attach to it. By adding a clause to the CREATE VIEW statement it is possible
to introduce explicit control. This is really all that is needed along with
an error when it cannot do what is requested of it. Like in the case of
asking for a default update when there is a JOIN. It should do one thing
consistently or fail, that's the principle I would like to see put in force.

Now, for those with whom these issues are a concern, they will make use of
the new explicit clause and solve their problems. Those who are fine with
things the way they are need not do anything about it. Omitting the new
clause leaves things behaving exactly as they are. Perhaps in a future major
release it would be appropriate to force explicit control of the default
actions, but people should have one version to adjust, I think.

I hope this clarifies my position on the matter.

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