> I'm not at all sure that an event interface built around single events
> is all that useful. If I were doing it, I'd want to ability to block on
> one of any number of events and the ability to get a callback from a
> dedicated listening thread.

What would be a business case for waiting on multiple events?

As I understand, the idea is to define an event USER_CHANGED, an AFTER
INSERT/UPDATE/DELETE trigger for USERS table that would fire such events.
Application that would register a listener for the case when USERS table is
changed. What would be the case to receive notifications for different
events in the same listener?

Roman