On Nov 11, 2009, at 10:43 PM, Tom Lane wrote:
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.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
