Re: Listen / Notify rewrite

On Nov 11, 2009, at 10:43 PM, Tom Lane wrote:

> Andrew Chernow <ac@esilo.com> writes:
>>> I thought of a compromise: add the number of times a notification  
>>> was
>>> generated (coalesced count+1) to the callback data. That would  
>>> satisfy
>>> any backwards compatibility concerns and my use case too!
>
>> If you are suggesting that the server poke data into the  
>> notifier's opaque
>> payload, I vote no.  Maybe the NOTIFY command can include a switch  
>> to enable
>> this behavior.  No syntax suggestions at this point.
>
> I agree, we should not have the system modifying the payload string  
> for
> this.  And don't bother suggesting a third column in the result ---
> we'd have to change the FE/BE protocol for that, and it's not going
> to happen.
>
> The existing precedent is that the system collapses identical
> notifications without payloads.  So we could possibly get away with
> saying that identical payload-less notifies are collapsed but those
> with a payload are not.  That doesn't really seem to satisfy the
> POLA though.  I think Joachim's definition is fine, and anyone who
> needs delivery of distinct notifications can easily make his payload
> strings unique to ensure it.

The notification count could be a secondary "payload" which does not  
affect the first, but I guess I'm the only one complaining about the  
coalescing...

-M