Search Postgresql Archives

Re: background triggers?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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...


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux