On Wed, Mar 19, 2008 at 11:37:16AM +1030, Tyler, Mark wrote:
Oh, you can, you can calculate the name of the NOTIFY dynamically
in the trigger sending the notify, for example embedding a primary key
value.
I don't understand how this can work. Surely my subscriber applications
have to
On Thu, Mar 20, 2008 at 12:40:46PM +0100, Karsten Hilbert wrote:
It's great fun to watch people from all across the globe
change data on test patients in our public test database.
The frontend is written to display such updates in realtime
(well, whatever it takes to get the notification
On Thu, Mar 20, 2008 at 02:08:13PM +0100, Martijn van Oosterhout wrote:
It's great fun to watch people from all across the globe
change data on test patients in our public test database.
The frontend is written to display such updates in realtime
(well, whatever it takes to get the
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
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 into the subscriber
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 the notify, for example
embedding a
On Mar 17, 2008, at 10:58 PM, 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
Wait a while and you will learn to detest Spread, too.
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 into
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 the
On Mar 19, 2008, at 2:35 AM, Tyler, Mark wrote:
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
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
Tyler, Mark escribió:
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
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
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 suggest
rethinking your
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
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? If the
transaction commits then the
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? If the
18 matches
Mail list logo
