On Fri, Nov 13, 2009 at 1:57 AM, Robert Haas <robertmh...@gmail.com> wrote: > I agree. We frequently reject features on the basis that someone > might do something stupid with them. It's lame and counterproductive, > and we should stop. The world contains infinite amounts of lameness, > but that's the world's problem, not ours. There is zero evidence that > this feature is only useful for stupid purposes, and some evidence > (namely, the opinions of esteemed community members) that it is useful > for at least some non-stupid purposes.
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. 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. You expect to spill to disk and need an efficient storage mechanism. The natural implementation of this in Postgres would be a table, not the slru. If you're designing a condition-variable mechanism then you would naturally use a hash table which can probably live in a single page with a simple flag for each variable. The comment in another thread that this mechanism should implement ACID properties just reinforces my reaction. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers