From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh Kupershmidt <schmiddy(at)gmail(dot)com> |
Cc: | Filip Rembiałkowski <filip(dot)rembialkowski(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: make NOTIFY list de-duplication optional |
Date: | 2016-02-09 20:17:59 |
Message-ID: | 19849.1455049079@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Kupershmidt <schmiddy(at)gmail(dot)com> writes:
> On Tue, Feb 9, 2016 at 2:16 PM, Filip Rembiakowski
> <filip(dot)rembialkowski(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2016-02-09 20:20:50 | Re: Multi-tenancy with RLS |
Previous Message | Tom Lane | 2016-02-09 20:10:15 | Re: pgsql: postgres_fdw: Push down joins to remote servers. |