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" <[EMAIL PROTECTED]>
To: "Iain" <[EMAIL PROTECTED]>
Cc: "Mike Rylander" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, September 16, 2004 12:57 PM
Subject: Re: [SQL] implementing an out-of-transaction trigger
>
> "Iain" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
