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
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
&g
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
I
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 t
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
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 messag
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 ta
