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!
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
