Ann W. Harrison wrote:

>
> There was discussion and agreement to change the behavior
> of naturally updateable views with triggers on the development
> list around 30 July 2003 and again in November 2003. Whether
> I was on vacation, asleep, or just stupid, I missed it.
>
> Dmitry and others found dozens of cases where views were
> marginally updateable, unreliably updateable, crashed the
> system etc. Dmitry's message is below.

Ann:

In our short FB history, controversial changes have been discussed and
tested in the list. Incompatible changes with previous versions (where the
old versions were considered at fault) were done after general agreement.
It's almost impossible that "general" equals "unanimous". You are arguing:

1.- To keep a bug.

2.- To keep stupid and nonsense behavior that has caused much grief.

3.- To keep behavior that -from memory- only one person found useful. Sorry,
as I wrote previously, you can't satisfy everyone.

4.- To avoid the education phase that comes after fixing a bug in a major
version. FB2 is a major version. Changes are expected or people may continue
at FB1.5 that will improve again when a new minor version is released
(that's not false promise; enough changes were backported after v1.5.1). The
same education cycle was done for FB1. You and I stopped dangerous
ambiguity, then parameter ordering was fixed by Nickolay, then invalid
aggregate constructions were stopped by Arno (although not enough for my
personal taste), then Dmitry fixed that damn double action in views, etc.,
and I'm sure I'm missing other cases in the middle. Although it doesn't
affect the syntax, Arno's index change counts also as an incompatible change
with the past. We have solved those steps with education. When it wasn't
enough, dialect 1 was left out of ambiguity checks to satisfy legacy ODBC
drivers and Nickolay provided a config value for old parameter ordering (I
prefer that value to be connection-specific, but that's me).

5.- To create a new syntax mess to satisfy the old behavior or to have to
add explicit statement to get the new behavior. Apparently the longer the
statements, the more you enjoy them. <g> In the rare event that I was
brainwashed to accept this proposal, I would elect to tax the old behavior
with the extra syntax. Having to specify additional keywords to get the new,
right, rational and standard behavior (that incidentally coincides with the
original design) simply flies in the face of reason. Order a "config param
breakfast" for the old behavior if you can't digest the new deportment as a
fixed solution.

6.- To revert a behavior that was discussed and agreed in the list. This is
how other changes happened. Sorry to ask, but is there anything that makes
you think you don't have to abide by our implicit development rules? You
come after the house is painted (or at least after the paint has been
purchased) and want to change the color. Hmm, I would say you're late when
the tickets are sold. You had had enough time to chime in. The same subject
was raised more than two years ago and you didn't complain either. Were you
absent or in a suspended state, too?

7.- To satisfy a marketing department that we don't have. Granted,
incompatible changes cause problems to the "customers", but unlike Borland,
we don't do arbitrary modifications. We have justified the upgrade problems
with the added benefit of a cleaner implementation and more deterministic
results from the server. Unlike MS, we don't force anyone to upgrade to the
latest version. Otherwise, no changes among the ones I listed would have
happened. Progress always comes from a crisis or causes a crisis. Live with
it.

C.