On Fri, Nov 13, 2009 at 1:57 AM, Robert Haas <robertmhaas@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