I'd like to propose a 'syntax/semantics' of such trigger: Triggers normally execute inside of a transaction. A COMMIT within a trigger could mean: "do a fork: fork-1) return to the main and schedule COMMIT there, fork-2) continue in bacground". >From the perspective of my earlier applications, it would be desired to have an argument for such COMMIT - a label, which is a *global* database object (may be just a semaphore), and is: 1) Assuming semaphore implementation - semaphore should be tested and fail if already asserted, NOT tesed an block. FORK should be initiated only if semaphore test succeeds. 2) the execution of procedure within fork-2 (meaning, after semaphore assertion succeeds) should be posponed until caller actually COMMITS. 3) On EXIT, fork-2 deasserts semaphore. 4) in the simplest case, the semaphore can be defined on the trigger function name itself, and consequently, the 'label' for the COMMIT wouldn't be necesary? -R On Thu, 2006-05-25 at 08:50 +0200, Sim Zacks wrote: > 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... > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org
