On Wed, 2006-05-24 at 13:36 +0200, Sim Zacks wrote: > My understanding of Listen/Notify is that it is a completely > disconnected process running on the database server.
Yes. But In my particular case (and I presume, the intention of 'bacground triggers' is that) a programmer (like myself) is not really interested in the outcome of thet trigger process. So there is no 'technical' need for him/her to create the server side proces *provided* hi/she can setup a job *within* the database server itself, and just go away. That's the idea of 'background triggers'. Surely, there are work arounds. Like the LISTEN/NOTIFY server (not datagase server, but system server) daemon that takes database server notiffications. And even a system server daemon, that simply uses synchronous database communication (like I did in my case). The problem is, that I have this 'eatching desire', to have such technical issues supported 'withing the framework of RDBM architecture'. That's why I keep thinking, that the solution I used is actually 'bitting the fances', while gurus do it some other, *better* way. But if not, a think that 'bakground triggers' could help here. > > I may not have understood exactly what you are trying to do, but from > what I understood, this will solve your problem. I think you did. I just feel that 'background triggers' is 'real life' engineering issue, so it should get some backing from RDBMS. just my 2c. -R ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
