Commented by: Sean Leyne (seanleyne)

This change would seem to create a significant problem for existing applications/systems.

Please explain why the proposed change is necessary (providing examples of why the current approach is deficient).

Commented by: Alexander Tyutik (tut)

> This change would seem to create a significant problem for existing applications/systems.

This problem can be solved simple way: when restoring for old ODS server should create empty INSTEAD OF trigger for each view.

> Please explain why the proposed change is necessary (providing examples of why the current approach is deficient).

It is very long story to explain why :-( But i'll try (sorry for my bad english).

What we have now? Now we have next problems:

When a man read command CREATE BEFORE/AFTER TRIGGER what will hi think? I think that this trigger executes BEFORE of AFTER command which i run for a view. But here we have a few problems:

1) Where is a time point of command? How can i define when it was "before" and when main command action was done and when it was "after"? I should open each trigger and look at it for this. It is not clear logic, so i think it is bad.

2) I run one command, for example INSERT. In current implementation i can write 512 triggers and all of them will run instead of my INSERT command. This is very very strange. Imagine that you defined virtual method in C++ (equal to our INSERT command). How can you override it by 512 different methods in same time in descendant class? It sounds silly. But in FB it is possible. So i think it is incorrect and server should allow to create only one INSTEAD OF trigger which will override standard behavior.

3) What if you have simple view like CREATE VIEW MY_VIEW AS SELECT * FROM MY_TABLE and you want to add trigger logic on a view only, not on table. For example you want to set default value to fiend in BEFORE trigger on view. But in current implementation this trigger will discard default insert and you should manually write INSERT INTO MY_TABLE command in this trigger. But you want to have standart automatic behavior and don't want your trigger discard it and you don't want to write insert command manually. But it is impossible in current implementation, so it is bad.

4) Triggers for views have same syntax as triggers for tables, but have different behavior (see 3). This is additional source of problems, so i think it is bad.