Now would it be so tough?

The table name could be made available through the new context
variable system, as could the column names. The PSQL routine could
use the "execute statement" syntax to work with dynamic SQL.

The tough part would be in the code path leading up to the trigger
firing, not in the actual firing & execution, imho.

Second, code to handle stored procedures and triggers in java or
dotNet already exists. It was presented at the 2005 conference by
Eugeny Putilin. The source has been donated to the project and
binaries are available in the free Fyracle download.

Paul

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

>
> Geoff Worboys wrote:
> >
> > Side Note: The above examples (logmanager, IBO DML stuff
> > and some of my own work) make me wonder whether it would be
> > possible to have "generic" table triggers. That is; define a
> > single before or after trigger than fires against all DML
> > (insert/update/delete on all user tables). To be useful such
> > triggers would need ways to interrogate what table is currently
> > being processed and what fields it has... so I expect this
> > would be non-trivial. However it would mean that instead of
> > needing some 200 functionally identical triggers for 200 tables
> > you could have just one. (Just a thought.)
> >
> I did that in Netfrastructure -- and it's a huge win.

Netfrastructure,

> however, uses embedded Java as the trigger environment, giving it a
> little more computational umph. Firebird, I'm afraid, uses the BLR
> engine as the trigger environment, so there is absolutely no way to

make

> table references soft. There was quite some chitchat a year ago

about

> pluggable engines, but design was specific to Firebird 2, so that's

not

> going to help much going forward.
>
> If I were to make a recommendation going forward, I would suggest

find a

> tame JVM, embedding it in Vulcan, and support Java based triggers.

Yes,

> it's a big piece of work, but work well worth doing. The down

side,

> unfortunately, will be a large chorus "but I don't know Java and I

want

> my xxx".
>
> But a single replication trigger handling insert, update, and

delete for

> all tables is really sublime.
>
>
> --
>
> Jim Starkey, Senior Software Architect
> MySQL AB, www.mysql.com
> 978 526-1376
>