Vivek Khera wrote:
Wait a while and you will learn to detest Spread, too.
I know this is probably off-topic for this group but why do you say
this? I guess I don't want to go too far down a particular route if
there are big traps waiting so I am interested in the basis for your
comment.
Mark
Alban Hertroys wrote:
On Mar 18, 2008, at 3:58 AM, Tyler, Mark wrote:
I suggest rethinking your dislike of NOTIFY.
I have thought very hard about using NOTIFY for this but it has two
large problems (from my point of view). The first is that it forces
me
to put far more smarts and state
Karsten Hilbert wrote:
On Tue, Mar 18, 2008 at 01:28:36PM +1030, Tyler, Mark wrote:
This
is because I cannot pass any information with the NOTIFY apart from
the fact that something happened.
Oh, you can, you can calculate the name of the NOTIFY dynamically
in the trigger sending
Hi,
I am trying to set up a PostGreSQL database to send asynchronous
notifications when certain inserts or updates are performed on the
tables. The idea is I want to have publish / subscirbe model with the
database in the centre as the information hub. An application will
insert a record into a
Rodrigo Gonzalez wrote:
I am almost sure you've defined a BEFORE trigger and
you need and AFTER trigger, so it's fired after commiting.
No - I am definitely using an AFTER trigger. Following is a simplified
version of what I am trying to do.
/* messages - log messages */
CREATE TABLE
Tom Lane wrote:
Tyler, Mark [EMAIL PROTECTED] writes:
What I want to do is to guarantee that the row is available for
selection prior to sending the message.
You cannot do that with an AFTER trigger, because whatever it
does necessarily happens before your transaction commits.
I somehow
Tom Lane wrote:
Tyler, Mark [EMAIL PROTECTED] writes:
Secondly, the lack of any delivery guarantee means my subscriber
applications may miss event notifications. This is a very bad thing
for my particular application.
What makes you think NOTIFY doesn't guarantee delivery
