Re: proposal: make NOTIFY list de-duplication optional

Поиск
Список
Период
Сортировка
От Josh Kupershmidt
Тема Re: proposal: make NOTIFY list de-duplication optional
Дата
Msg-id CAK3UJRE3wdNj0_qB-dgb+JAj3iXFNtjSf649o3hh45QtayxS8Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: make NOTIFY list de-duplication optional  (Filip Rembiałkowski <filip.rembialkowski@gmail.com>)
Ответы Re: proposal: make NOTIFY list de-duplication optional  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Tracing down buildfarm "postmaster does not shut down" failures
Следующее
От: Tom Lane
Дата:
Сообщение: Re: proposal: make NOTIFY list de-duplication optional