Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On 3/11/16 1:46 PM, David Steele wrote: Hi Filip, On 2/20/16 8:00 AM, Filip Rembiałkowski wrote: On Fri, Feb 19, 2016 at 10:09 PM, Catalin Iacob > wrote: > FWIW, I think it would be a good

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

Hi Filip, On 2/20/16 8:00 AM, Filip Rembiałkowski wrote: > On Fri, Feb 19, 2016 at 10:09 PM, Catalin Iacob On 2/9/16, Tom Lane > > wrote: > > FWIW, I think it would be a good thing if the NOTIFY statement syntax

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On Sat, Feb 20, 2016 at 2:00 PM, Filip Rembiałkowski wrote: > I was stuck because both syntaxes have their ugliness. NOTIFY allows the > payload to be NULL: > NOTIFY chan01; > > How would this look like in "never" mode? > NOTIFY chan01, NULL, 'never'; -- seems very

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On Fri, Feb 19, 2016 at 10:09 PM, Catalin Iacob wrote: > On 2/9/16, Tom Lane wrote: > > 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 > >

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On 2/9/16, Tom Lane wrote: > 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

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

Another update - separated new internal function to satisfy opr_sanity.sql diff --git a/contrib/tcn/tcn.c b/contrib/tcn/tcn.c index 7352b29..3a6d4f5 100644 --- a/contrib/tcn/tcn.c +++ b/contrib/tcn/tcn.c @@ -160,7 +160,7 @@ triggered_change_notification(PG_FUNCTION_ARGS)

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

Small update. I had to add one thing in /contrib/tcn/. diff --git a/contrib/tcn/tcn.c b/contrib/tcn/tcn.c index 7352b29..3a6d4f5 100644 --- a/contrib/tcn/tcn.c +++ b/contrib/tcn/tcn.c @@ -160,7 +160,7 @@ triggered_change_notification(PG_FUNCTION_ARGS) strcpy_quoted(payload,

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On Tue, Feb 9, 2016 at 2:16 PM, Filip Rembiałkowski 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 ] >

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

Josh Kupershmidt writes: > On Tue, Feb 9, 2016 at 2:16 PM, Filip Rembiałkowski > wrote: >> But then it becomes disputable if SQL syntax change makes sense. >> >> ---we had this, >> NOTIFY channel [ , payload ] >> ---and in this patch we have

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On Tue, Feb 9, 2016 at 12:15 AM, Merlin Moncure 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

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On 8 February 2016 at 09:37, Filip Rembiałkowski < filip.rembialkow...@gmail.com> wrote: > On Sun, Feb 7, 2016 at 4:37 PM, Vik Fearing wrote: > > >>> There is also no mention in the documentation about what happens if I > do: > >>> > >>> NOTIFY ALL chan, 'msg'; > >>>

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On 02/08/2016 09:33 PM, Filip Rembiałkowski wrote: > Here is my next try, after suggestions from -perf and -hackers list: > > * no GUC > > * small addition to NOTIFY grammar: NOTIFY ALL/DISTINCT > > * corresponding, 3-argument version of pg_notify(text,text,bool) > > * updated the docs to

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On Mon, Feb 8, 2016 at 1:52 PM, Craig Ringer wrote: > Would it be correct to say that if ALL is specified then a message is queued > no matter what. If DISTINCT is specified then it is only queued if no > message with the same channel and argument is already queued for

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On Mon, Feb 8, 2016 at 2:33 PM, Filip Rembiałkowski wrote: > Here is my next try, after suggestions from -perf and -hackers list: > > * no GUC > > * small addition to NOTIFY grammar: NOTIFY ALL/DISTINCT > > * corresponding, 3-argument version of

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On Sun, Feb 7, 2016 at 11:54 AM, Vik Fearing wrote: > On 02/07/2016 03:42 AM, Filip Rembiałkowski wrote: > You left the duplicate behavior with subtransactions, but didn't mention > it in the documentation. If I do NOTIFY DISTINCT chan, 'msg'; then I > expect only

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On 02/07/2016 04:00 PM, Filip Rembiałkowski wrote: > On Sun, Feb 7, 2016 at 11:54 AM, Vik Fearing wrote: >> I seem to remember some discussion about not using DEFAULT parameters in >> system functions so you should leave the old function alone and create a >> new function

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On 02/07/2016 03:42 AM, Filip Rembiałkowski wrote: > +1 > > ... and a patch (only adding ALL keyword, no hash table implemented yet). Please stop top-posting, it's very disruptive. My comments are below, where they belong. > On Sat, Feb 6, 2016 at 2:35 PM, Brendan Jurd

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On Sun, Feb 7, 2016 at 4:37 PM, Vik Fearing wrote: >>> There is also no mention in the documentation about what happens if I do: >>> >>> NOTIFY ALL chan, 'msg'; >>> NOTIFY ALL chan, 'msg'; >>> NOTIFY DISTINCT chan, 'msg'; >>> NOTIFY ALL chan, 'msg'; >>> >>>

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

Brendan Jurd writes: > On Sat, 6 Feb 2016 at 12:50 Tom Lane wrote: >> Yeah, I agree that a GUC for this is quite unappetizing. > How would you feel about a variant for calling NOTIFY? If we decide that this ought to be user-visible, then an extra NOTIFY

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On 02/05/2016 08:49 PM, Tom Lane wrote: Yeah, I agree that a GUC for this is quite unappetizing. Agreed. One idea would be to build a hashtable to aid with duplicate detection (perhaps only once the pending-notify list gets long). Another thought is that it's already the case that

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

+1 ... and a patch (only adding ALL keyword, no hash table implemented yet). On Sat, Feb 6, 2016 at 2:35 PM, Brendan Jurd wrote: > On Sat, 6 Feb 2016 at 12:50 Tom Lane wrote: >> >> Robert Haas writes: >> > I agree with what

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On Sat, 6 Feb 2016 at 12:50 Tom Lane wrote: > Robert Haas writes: > > I agree with what Merlin said about this: > > > http://www.postgresql.org/message-id/CAHyXU0yoHe8Qc=yc10ahu1nfia1tbhsg+35ds-oeueuapo7...@mail.gmail.com > > Yeah, I agree that a GUC

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

Robert Haas writes: > On Fri, Feb 5, 2016 at 10:17 AM, Filip Rembiałkowski > wrote: >> - new GUC in "Statement Behaviour" section, notify_duplicate_removal > I agree with what Merlin said about this: >

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On Fri, Feb 5, 2016 at 10:17 AM, Filip Rembiałkowski wrote: > - new GUC in "Statement Behaviour" section, notify_duplicate_removal > (default true) > > Initial discussion in this thread: >