> This would be a very starting point for virtual tables. Rather than
> having a NULL table table,

NULL table is not necessary. It is just an implementation detail which
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 trigger
> mechanisms without change. It also gives a good place to implement
> system monitoring functions.

You don't know it of course but few virtual tables already committed
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 a
> 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
> context.

Think about logging into external location or about audit which must
log all user action despite of will it be committed or rolled back

Regards,
Vlad