From: | Andrew Chernow <ac(at)esilo(dot)com> |
---|---|
To: | Joachim Wieland <joe(at)mcknight(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Listen / Notify rewrite |
Date: | 2009-11-12 13:25:27 |
Message-ID: | 4AFC0CC7.7000006@esilo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>> 2. The payload parameter is optional. A notifying client can either call
>>> "NOTIFY foo;" or "NOTIFY foo 'payload';". The length of the payload is
>>> currently limited to 128 characters... Not sure if we should allow longer
>>> payload strings...
>> Might be a good idea to make the max the same as the max length for
>> prepared transaction GUIDs? Not sure anyone would be shipping those
>> around, but it's a pre-existing limit of about the same size.
>
> Yes, sounds reasonable to have the same limit for user-defined identifiers...
>
[..begging..] Can this be increased significantly? I don't get it, is there any
technical reason to make the limit soo small? This drastically reduces the
usefulness of the payload. I've wanted this feature for quite sometime and it
is quite disappointing that I could not even use it because it is unjustifiably
limited.
One use case I need is making the payload an absolute path, which saves us a
round trip (commonly internet latency) and a query in a section of the system
that's extremely performance sensitive. That sure ain't going to fit in 128
bytes.
I'm sure I'm not the only one who finds this limit too small. I can almost
guarentee complaints would come in if released that way.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2009-11-12 13:57:34 | Re: not logging caught exceptions |
Previous Message | Alvaro Herrera | 2009-11-12 13:22:04 | Re: New VACUUM FULL |