Re: proposal: make NOTIFY list de-duplication optional
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Josh Kupershmidt <schmiddy@gmail.com>
Cc: Filip Rembiałkowski <filip.rembialkowski@gmail.com>, Merlin Moncure <mmoncure@gmail.com>, Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2016-02-09T20:17:59Z
Lists: pgsql-hackers
Josh Kupershmidt <schmiddy@gmail.com> writes: > On Tue, Feb 9, 2016 at 2:16 PM, Filip Rembiakowski > <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 ] ] > What about adopting the options-inside-parentheses format, the way > EXPLAIN does nowadays, something like: > NOTIFY (DEDUPLICATE FALSE, MODE IMMEDIATE) mychannel; FWIW, I think it would be a good thing if the NOTIFY statement syntax were not remarkably different from the syntax used in the pg_notify() function call. To do otherwise would certainly be confusing. So on the whole I'd go with the "NOTIFY channel [ , payload [ , mode ] ]" option. regards, tom lane
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