Re: proposal: make NOTIFY list de-duplication optional
Josh Kupershmidt <schmiddy@gmail.com>
From: Josh Kupershmidt <schmiddy@gmail.com>
To: Filip Rembiałkowski <filip.rembialkowski@gmail.com>
Cc: Merlin Moncure <mmoncure@gmail.com>,
Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2016-02-09T20:09:56Z
Lists: pgsql-hackers
On Tue, Feb 9, 2016 at 2:16 PM, Filip Rembiałkowski <filip.rembialkowski@gmail.com> wrote: > But then it becomes disputable if SQL syntax change makes sense. > > ---we had this, > NOTIFY channel [ , payload ] > ---and in this patch we have this > NOTIFY [ ALL | DISTINCT ] channel [ , payload ] > --- but maybe we should have this? > NOTIFY channel [ , payload [ , mode ] ] I think using ALL to mean "don't worry about de-duplication" could be a bit confusing, especially as there was some interest recently in supporting wildcard notifications: http://www.postgresql.org/message-id/52693FC5.7070507@gmail.com and conceivably we might want to support a way to notify all listeners, i.e. NOTIFY * as proposed in that thread. If we ever supported wildcard notifies, ALL may be easily confused to mean "all channel names". What about adopting the options-inside-parentheses format, the way EXPLAIN does nowadays, something like: NOTIFY (DEDUPLICATE FALSE, MODE IMMEDIATE) mychannel; Josh
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Use a hash table to de-duplicate NOTIFY events faster.
- bb5ae8f6c416 13.0 landed