On Thu, Nov 12, 2009 at 11:39 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Nov 12, 2009 at 11:30 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Joachim Wieland <j...@mcknight.de> writes: >>> However I share Greg's concerns that people are trying to use NOTIFY >>> as a message queue which it is not designed to be. >> >> Yes. Particularly those complaining that they want to have very large >> payload strings --- that's pretty much a dead giveaway that it's not >> being used as a condition signal. >> >> Now you might say that yeah, that's the point, we're trying to enable >> using NOTIFY in a different style. The problem is that if you are >> trying to use NOTIFY as a queue, you will soon realize that it has >> the wrong semantics for that --- in particular, losing notifies across >> a system crash or client crash is OK for a condition notification, >> not so OK for a message queue. The difference is that the former style >> assumes that the authoritative data is in a table somewhere, so you can >> still find out what you need to know after reconnecting. If you are >> doing messaging you are likely to think that you don't need any backing >> store for the system state. >> >> So while a payload string for NOTIFY has been on the to-do list since >> forever, I have to think that Greg's got a good point questioning >> whether it is actually a good idea. > > I think there could be cases where the person writing the code can > know, extrinsic to the system, that lost notifications are OK, and > still want to deliver a payload. But I think the idea of enabling a > huge payload is not wise, as it sounds like it will sacrifice > performance for a feature that is by definition not essential to
'premature optimization is the root of all evil' :-) merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers