Re: Problem with async notifications of table updates

From: Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl>
To: "Tyler, Mark" <Mark(dot)Tyler(at)dsto(dot)defence(dot)gov(dot)au>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-general(at)postgresql(dot)org>
Subject: Re: Problem with async notifications of table updates
Date: 2008-03-18 07:06:10
Message-ID: 8120F54C-36E2-454D-931B-616EDFFFF47E@solfertje.student.utwente.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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 applications.
> This
> is because I cannot pass any information with the NOTIFY apart from
> the
> fact that "something happened". Due to this restriction my subscriber
> apps would have to go and look up some secondary table to get
> sufficient
> information to construct the real query. That is just plain ugly in my
> view.

You will have the same problem if you want to send a message about a
record change in combination with transactions. You can either send a
message about an /uncommitted/ transaction and include what record
changed, /or/ you send a message about a /committed/ transaction
which possibly changed multiple of those records - in which case
there's no possibility to send a single id along with your message.
You could try sending a set after commit, equivalent to how INSERT
RETURNING works, but you'll have to marshall those id's into your
message yourself. And that's pretty similar to putting those id's in
a table and fetch them from your application - it's just moving the
work around.

Regards,

Alban Hertroys

--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.

!DSPAM:737,47df69e69781418010441!

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Gurjeet Singh 2008-03-18 07:20:57 Re: identify database process given client process
Previous Message Shane Ambler 2008-03-18 06:51:00 Re: identify database process given client process