From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Joachim Wieland <joe(at)mcknight(dot)de>, Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Andrew Chernow <andrew(at)esilo(dot)com> |
Subject: | Re: Listen / Notify rewrite |
Date: | 2009-11-13 01:44:51 |
Message-ID: | 4AFCBA13.9050709@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Payloads are also quite useful even in a lossy environment, where you
understand that LISTEN is not a queue. For example, I'd like to be
using LISTEN/NOTIFY for cache invalidation for some applications; if it
misses a few, or double-counts them, it's not an issue. However, I'd
like to be able to send message like players_updated|45321 where 45321
is the ID of the player updated.
--Josh Berkus
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2009-11-13 01:46:13 | Re: Patch committers |
Previous Message | James Pye | 2009-11-13 01:42:29 | Re: Python 3.1 support |