From: | Rafal Pietrak <rafal(at)zorro(dot)isa-geek(dot)com> |
---|---|
To: | Sim Zacks <sim(at)compulab(dot)co(dot)il> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: background triggers? |
Date: | 2006-05-24 11:31:32 |
Message-ID: | 1148470293.20217.118.camel@model.home.waw.pl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Sim Zacks | 2006-05-24 11:36:18 | Re: background triggers? |
Previous Message | Ivan Zolotukhin | 2006-05-24 11:13:50 | Re: Clearing out old idle connections |