Andrew Chernow <a...@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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
