> 1. The RDB$TRIGGERS table would need at least a RDB$FIELD_NAME
> column to tie the trigger to a domain (leaving RDB$RELATION_NAME
> null). This would break an unknown number of DDL handling
> programs in unknownable ways.

On a RDB$TRIGGER_FIELDS table, which would not break DDL handling programs
as badly, they just wouldn't support the new feature.

> 2. There is no obviously way to merge trigger fire order from the
> domain space into the table space.

Triggers fire in order according to their sequence number, regardless of
whether they are defined in the table space or the domain space. Domain
trigger 3 fires after Table trigger 2, but before Table trigger 4. Triggers
with the same sequence resolve as they do now... By order of creation, is
it? In other words, it shouldn't matter if the trigger is defined in the
table space or the domain space. Possibly allow triggers defined in the
domain space a keyword that forces them to fire before tablespace triggers?

> 3. Mechanism that require multiple fields are hosed. My example
> would work, but if it were extended with previous_update_date
> and previous_update_user, it couldn't.

Arf. No thoughts on this one yet.

--
Mark Shapiro
Software Engineer
Segue Technologies, Inc.
http://www.seguetech.com/