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