Re: Listen / Notify rewrite

On Nov 12, 2009, at 5:57 PM, Robert Haas wrote:

> On Thu, Nov 12, 2009 at 8:44 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> On 11/12/09 8:30 AM, Tom Lane wrote:
>>> 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.
>>
>> Sure, people will abuse it as a queue.  But people abuse arrays when
>> they should be using child tables, use composite types to make data
>> non-atomic, and use dblink when they really should be using schema.
>> Does the potential for misuse mean that we should drop the features?  No.
>
> 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.

Speaking as a consumer of this feature, my (mild) concern is not that by
adding functionality it will make it possible to do new things badly, it's that
it might make it harder (or impossible) to do currently supported things as well.

I like the current notify. It's a good match for handling table based
queues or for app-level-cache invalidation. Any changes that make
it less good at that would be a step backwards. The more complex
and flexible and "heavier" the changes, the more that concerns me.

(Though a small payload - I'd settle for at least an integer - would be
convenient, to allow invalidation of 20 different caches without needing
20 different LISTENs).

Cheers, Steve