"Ann W. Harrison" <aharrison@...> wrote:

>
> Firebird 2 changes the semantics of inserts, updates, and
> deletes from naturally updatable views with triggers.
>
> In the early dark ages adding a user trigger to a naturally
> updatable view blocked the natural update. During the great
> SQL shift in V4, the rules were changed so the natural update
> did take place whether or not triggers were present.
>
> Reasonable people may disagree about whether that was a good
> thing. However, that is the way that InterBase and Firebird
> have worked for nearly 10 years.

And lots of people had troubles with this behaviour. IIRC the discussion in
fb-devel, only Nando considered it a feature that he would miss. I answer
support questions in Russian newsgroups and I'm quite tired to explain this
not-obvious-at-all behaviour again and again. Almost every people I had a
private talk with considered it a bug. You may also take a look at the SQL
spec regarding INSTEAD OF triggers.

My opinion is that this behaviour is incorrect and not standard compliant.
Even its existence for 10 years is not a good excuse. If we want some level
of legacy support, please consider a compatibility config option or suggest
another kind of backward compatibility switches. I'm 100% for compatibility.
But please don't consider it a nice-to-have feature and please don't extend
the syntax to accomodate this semantics. Everything that people may want to
do with triggers on naturally updatable views (usually logging) can be done
inside view triggers only.


Dmitry