Re: proposal: make NOTIFY list de-duplication optional - Mailing list pgsql-hackers

From Filip Rembiałkowski
Subject Re: proposal: make NOTIFY list de-duplication optional
Date
Msg-id CAP_rww=aTu4MLPxXapUqBotSme1msr6m9st3iPSTd+fQoY4vNQ@mail.gmail.com
Whole thread Raw
In response to Re: proposal: make NOTIFY list de-duplication optional  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: proposal: make NOTIFY list de-duplication optional
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)
Next
From: Christian Ullrich
Date:
Subject: Re: pl/pgSQL, get diagnostics and big data