Re: proposal: make NOTIFY list de-duplication optional

Поиск
Список
Период
Сортировка
От Filip Rembiałkowski
Тема Re: proposal: make NOTIFY list de-duplication optional
Дата
Msg-id CAP_rww=aTu4MLPxXapUqBotSme1msr6m9st3iPSTd+fQoY4vNQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: make NOTIFY list de-duplication optional  (Merlin Moncure <mmoncure@gmail.com>)
Ответы Re: proposal: make NOTIFY list de-duplication optional  (Josh Kupershmidt <schmiddy@gmail.com>)
Список pgsql-hackers
On Tue, Feb 9, 2016 at 12:15 AM, Merlin Moncure <mmoncure@gmail.com> wrote:

> I wonder if the third argument
> should be a boolean however.  If we make it 'text, 'send mode',
> instead, we could leave some room for more specialization of the
> queuing behavior.
>
> For example, we've had a couple of requests over the years to have an
> 'immediate' mode which dumps the notification immediately to the
> client without waiting for tx commit. This may or may not be a good
> idea, but if it was ultimately proved to be, it could be introduced as
> an alternate mode without adding an extra function.

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'm not sure which direction is better with non-standard SQL additions.
Recycling keywords or adding more commas?



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)
Следующее
От: Christian Ullrich
Дата:
Сообщение: Re: pl/pgSQL, get diagnostics and big data