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 mailto:t...@sss.pgh.pa.us>>
wrote:
> FWIW, I think it would be a good thing if the NOTIFY statement syntax
were
> not remarkably diffe
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 mailto:t...@sss.pgh.pa.us>>
> wrote:
> > FWIW, I think it would be a good thing if the NOTIFY statement syntax
> were
> > not remarkably different from t
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 cryptic.
The docs say:
"The inf
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
> > call. To do otherwise would certainly be confusi
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 channel [ , payload
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)
strcpy_quoted(payload
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, SPI_getvalue(trigt
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 this
>> NOTIFY [ ALL | DISTINCT ] channel [ , payload
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 ]
> --- but maybe we should have t
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 of requests over the
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 pg_notify(text,text,bool)
This is all sounding pret
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 inclu
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 delivery.
Yes, exactly.
>
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';
> >>> NOTIFY ALL chan, 'msg
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';
>>>
>>> Without testing, I'd sa
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 with your use_all paramet
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 distinct notifications but I'
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 wrote:
>> On Sat, 6 Feb
+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 Merlin said about this:
>> >
>> > http://www.postgresql.org/message-
On Sat, Feb 6, 2016 at 5:52 PM, Tom Lane wrote:
> 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
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 duplic
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
parameter would be the way to do it. I'd
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 for this is quite unappetizing.
>
How would
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:
> http://www.postgresql.org/message-id/CAHyXU0yoHe8Qc=yc10ahu1nfia1tbhsg+35ds-oeueuapo7...@mail
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:
> http://www.postgresql.org/message-id/CAP_rwwmpzk9=sbjrztod05bdctyc43wnknu_m37dygvl4sa...@mail.gmail.com
>
> R
- new GUC in "Statement Behaviour" section, notify_duplicate_removal
(default true)
Initial discussion in this thread:
http://www.postgresql.org/message-id/CAP_rwwmpzk9=sbjrztod05bdctyc43wnknu_m37dygvl4sa...@mail.gmail.com
Rationale: for some legitimate use cases, duplicate removal is not
require
26 matches
Mail list logo