Re: send/receive buffer size

Is it possible to establish a better issue tracking system than this
static http://jdbc.postgresql.org/todo.html or mailing list? So that
community knows what is going on? What to expect in next release.

Since the project is hosted on github now. Why not leverage it's build-in
features? https://github.com/features/projects/issues
__________________________

Shijun Kong

On 8/21/12 7:08 PM, "Scott Harrington" <scotth01(at)sns-usa(dot)com> wrote:

>On Tue, 21 Aug 2012, Shijun Kong wrote:
>
>> I read a thread somewhere that somebody contributed a patch for adding
>>support of configurable send/receive buffer size. Did it ever commit into
>> master branch? I did not see any commit message about this change for
>>last 12 months.
>
>I wondered the same last weekend and found that the patch had NOT yet
>found its way into pgjdbc on github. In case it helps you, I've attached
>that old patch in a form that should apply cleanly against the latest
>sources (unless something's changed in the last 10 days).
>
>Before merging, maintainers would probably want to rename the property
>names (which have underscores in this patch) to better conform to the
>other driver properties which use camelcaps for the most part.
>
>I have also attached a "localAddress" patch that I find useful (I think I
>posted it myself a while ago, but in any case here's an updated patch
>that
>should apply more cleanly against recent sources).
>
>-Scott

This email message and any attachments may contain legally privileged or confidential information intended solely for the use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution or copying of this message or its attachments is strictly prohibited. If you have received this message in error, please notify us immediately by telephone, fax or email and delete the message and all attachments to the message. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Investor Analytics LLC.