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.
You guys are assuming it's being used in a queue, which is only a fraction of cases where this feature is useful. In fact, having a payload can remove the need for a queue completely where is currently required for no other reason to deliver payload messages. I'm sorry, the 128 character limit is simply lame (other than for unsolvable implementation/performance complexity which I doubt is the case here), and if that constraint is put in by the implementation, than the implementation is busted and should be reworked until it's right. A feature that is being used for things not intended is a sign of a strong feature, not a weak one, and the idea that a payload should be length limited in order to prevent use in ways that are 'wrong' is a very weak argument IMO. People have been asking for this feature since the beginning of time, and nobody said: 'please limit it to 128 bytes'. A limit of 4k - 64k is much more appropriate if you even want a hard limit at all... merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
