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!
