Re: implementing an out-of-transaction trigger

Hi Greg,

I would have like to have avoided writing a daemon if possible, but
presumably it should be possible to write one flexible enough to be used in
a variety of situations.

If I didn't use notify, I'd would just be checking for the presence of data
in "transfer areas" or queue tables as you called them on a periodic basis.
This wouldn't change so much using notify, except that instead of writing
the process so as to sleep and periodically check, I can just have it wake
up when the data actually gets there. A minor saving perhaps, but at least I
could use the name of the notification to determine what processing to
activate.

Thanks,
Iain
----- Original Message -----
From: "Greg Stark" <gsstark(at)mit(dot)edu>
To: "Iain" <iain(at)mst(dot)co(dot)jp>
Cc: "Mike Rylander" <mrylander(at)gmail(dot)com>; <pgsql-sql(at)postgresql(dot)org>
Sent: Thursday, September 16, 2004 12:57 PM
Subject: Re: [SQL] implementing an out-of-transaction trigger

>
> "Iain" <iain(at)mst(dot)co(dot)jp> writes:
>
> > Though, as far as I can tell, there is no way to have the notify
activate a
> > pl/pgsql function directly. I'll still need to write a client program to
> > create a session and actually do the listening, that is if I havn't
missed
> > anything else...
>
> Right, presumably some sort of daemon that sits and waits for events. Much
> like you would have with Oracle advanced queuing and such.
>
> The big difference is that NOTIFY doesn't pass along any parameters. You
will
> need some way for your daemon to find any pending data it needs to
process.
> You might need some kind of queue table, or you might be able to get by
> without one.
>
> --
> greg