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!
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 |