|Subject||Re: [Firebird-Architect] Database triggers|
> This would be a very starting point for virtual tables. Rather thanNULL table is not necessary. It is just an implementation detail which
> having a NULL table table,
have absolutely no meaning regarding feature's nature. And i'm sure
we can avoid it.
> create suitable virtual tables for connection and transaction data.What will return select from such table ?
> This will allow you to use the standard triggerYou don't know it of course but few virtual tables already committed
> mechanisms without change. It also gives a good place to implement
> system monitoring functions.
in HEAD :) And it serve system monitoring functions. They presented
system state snapshot in relational form. This snapshot don't mantained
by engine all the time but created only by user request, so it is impossible
to have usual triggers for virtual tables. My strong opinion is that this
implementation much cheaper for engine than real-time update of some
persistent data from which virtual tables can be queried
> What account do the trigger run under?Under account of user who initiated action. All proposed triggers
fired at moment where valid user account is established
> Stepping back, you proposal is written as a solution looking for aThink about logging into external location or about audit which must
> problem. It would be easier to evaluate if you started by saying what
> problem you are trying to solve. Then we could evaluate the proposal in
log all user action despite of will it be committed or rolled back