Re: background triggers?

The question is not how it is implemented, the question is what does the
end user have to do to accomplish his requirements. If I have to write
my own daemon, then I have to debug it and maintain it, write a script
so it automatically turns on when the machine is rebooted. If I have
multiple environments, for development, testing and production, I will
need to modify it to handle this. If I move the database to a new server
this script has to be in the action items to be moved along with its
accompanying start-up scripts. If I decide to recover a backup to test
something (something I do on an occasional basis), I will need to
consider my daemon as well. It is basically an outside process that has
a lot of overhead (not necessarily computing overhead).

If the database supported background triggers, it might be implemented
by a daemon or by the Listen/Notify framework, but I really couldn't
care less. It is part of the database. I only need to write the function
and the trigger code with an option to run this in the background. No
matter what I do now, or how many environments I have, the database
handles it all. If I backup my database and install it on another
server, my process is still intact.

The reason why this should be part of the database engine and not
another client application is because what you want is a trigger. All
you want is when a table is updated that another function should run,
you don't need any outside processing. The Listen/Notify framework is
needed for a case where you would like non-database actions to take
place. Your client application can then go and do what it needs to and
then comes back and can tell the database that it is done.

Chris Browne wrote:

> Well, you *clearly* need to have some sort of "daemon" running in
> order to do this.
>
> I expect it will in effect be a LISTEN process that waits for clients
> to submit NOTIFY requests.
>
> Even if you don't actually choose to use NOTIFY/LISTEN, per se, you'll
> doubtless wind up creating an ad hoc, informally-specified
> implementation of part of it...