We have two viewpoints:
- this behaviour is wrong, undocumented, non-standard, used by very
few app's and a support headache
- changing this behaviour will break thousands of production systems

I do not have hard numbers, I would assume that the most likely class
of app's to break are replication tools. This would indeed be a
support nightmare: people upgrade the engine and suddenly their
replication stops working -- replication vendors get swamped with
support calls and in-house solutions go digging for that old, non-
existing documentation. Heck, it always used to work.

I am somewhat surprised that Sean's suggestion of some sort of
config/dialect based solution did not get more discussion. Seems a
sensible approach to me.

Paul

PS For Fyracle the decision does not matter much -- it has its own
parser.

--- In Firebird-Architect@yahoogroups.com, Jim Starkey <jas@n...>
wrote:

> Claudio Valderrama C. wrote:
>
> >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".
> >
> So, you are arguing that a single keyword on future view

definitions is

> too hgih a price to pay to keep thousands of existing production

systems

> working? Or are you arguing that an implicit decision once made

cannot

> be reviewed?
>
>
> [Non-text portions of this message have been removed]