"Jim Starkey" <jas@...> wrote:

>
> If you want to play in the software business, you must accept that
> breaking working production systems because you have a better idea
> doesn't work. It doesn't mean that your idea isn't better, it just
> means that better doesn't trump working.

I prefer to spot legacy issues, document them, provide a compatibility
option and declare the problematic features deprecated in the future
versions. Declaring them valid features and providing new syntax to
accomodate both semantics is not the way I see it, sorry.

If we don't consider it an useful feature, then why we're about to create a
new syntax? Otherwise, please convience me that it's useful. So far I see
that:

1) everything can be done with the original update semantics, so no
functionality is lost
2) the "new" (with 10 years of history <g>) semantics is proven to give
users troubles
3) the SQL spec declares INSTEAD OF triggers which disable any direct view
updates
4) major RDBMS players support only the standard (and our original)
semantics
5) the "new" semantics is not documented at all:

"You can specify nondefault behavior for updatable views, as well. InterBase
does not
perform writethroughs on any view that has one or more triggers defined on
it. This
means that you can have complete control of what happens to any base table
when
users modify a view based on it."

(c) InterBase 6.0 Data Definition Guide

I'm pretty sure that we have lots of people who's not aware of the semantics
you're trying to protect. They create triggers to update a view and usually
don't notice the statistics reporting about double table updates. Those who
happen to update such a view containing blob fields, got "Invalid blob ID"
errors because of this double update (I said "got" because Nickolay has
fixed this bug in HEAD).

> Ann's solution of adding a keyword to create view is backwards
> compatible, solves the problem, has minimal impact, and is trivial to
> implement (unless we've run out of flags in RDB$RELATIONS).

I have no objections if we do consider it a feature. But, given the above
explanations, I'm sure we don't need this "feature".


Dmitry