I agree with you that it would be better to have a background trigger
run by the database server. That was exactly what I asked. The answer
was that there is no current way to do a background trigger and to
accomplish what I want to do I need to write a daemon that calls Listen
and then on the Notify run my function.
If background triggers were a possibility that would make the whole
thing so much easier.
Rafal Pietrak wrote:
> 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
>