-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160
> This is BS. The problem is not that someone might do something stupid > with this feature. The problem is that we're making these other use > cases into requirements which will influence the design. This is a > classic "feature creep" situation and the result is normally products > which solve none of the use cases especially well. Feature creep? The payload has been on the roadmap for a long time. I don't recall anyone objecting when Andrew was working on the next version of Listen/Notify around what is probably a couple of years ago now. > Remember this queue has to live in shared memory which is a fixed size > resource. If you're designing a queue mechanism then you would > naturally use something like a queue or priority queue. Right, but we're not discussing a queue, we're discussing the listen/notify system. If people want to mis-use it as a queue when they should be using something else, so be it. Talk of efficiency also seems silly here - using shared memory is already way more efficient than our current listen/notify system. - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 200911131234 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkr9mL0ACgkQvJuQZxSWSshkvACg6OQ/SRjkvmozzUogTX3weuio 4ZoAnRVfvcrdMmo+iKtkyXmhAlZqViqF =6fzv -----END PGP SIGNATURE----- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
