Re: Listen / Notify rewrite

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Tom Lane writes:

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

I don't want "large" but I do think an arbitrary limit of 128 is odd without
some justfication. I could do 128, but would probably be happier with a bit
more room.

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

That's putting an awful lot of assumptions on what people are going to do
in the future, and also not being imaginative enough for circumstances
in which a payload which is not system crash survivable is a completely
acceptable condition. In most of my use cases, even desired. People wanting
a real queue can continue to use something other than NOTIFY.

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

Absolutely is a good idea.

Agent M asks:

> The notification count could be a secondary "payload" which does not
> affect the first, but I guess I'm the only one complaining about the
> coalescing...

Er...this thread is only a few hours old. For the record, I'm fine with the
coalescing as we do now (at least as far as my own selfish purposes :)

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200911121836
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkr8nCwACgkQvJuQZxSWSsjQIgCgjH60LlZYEek9FwcD+/w4IHYQ
PWwAnR0YxdSBm5iBa+G+T1VpIP4qjJsx
=Ju0P
-----END PGP SIGNATURE-----