On Mon, 18 Apr 2011, Mike Fowler wrote:
> On 18/04/11 17:12, Tom Lane wrote:
>> Dave Cramer<pg@fastcrypt.com> writes:
>>> Well initially my concern was that people would have a challenge in
>>> the case where they had to re-certify their application if we made
>>> this change, however I realize they will have to do this anyway since
>>> upgrading to 9.1 is what necessitates it.
>> I don't see any backwards compatibility risk, if that's what you mean.
>> Every backend release since 7.3 has treated client_encoding 'UTF8' and
>> 'UNICODE' the same, and earlier releases didn't accept either one.
>>
>> regards, tom lane
>>
>
> As there seems to be a consensus forming for fixing the JDBC driver, I've
> taken the liberty do so at the risk of being shot down. The patch is fairly
> straightforward, just changing UNICODE to UTF8 in a number of files including
> the translation files. I've tested this against 9.1devel (HEAD) and 8.4.7.
> For each database version I build and the tests running JDKs 1.4.2_19,
> 1.5.0_22 and 1.6.0_2. All on 32-bit.
>
Thanks, applied, mostly. It's great to have a patch for a problem before
you even know it exists.
I didn't modify the .po files. I doubt this will change the adjacent
translation wording, but directly patching .po files is only something to
do in more dire circumstances (like needing to make a backpatch to an old
branch that won't get translators to look at it before the next release.)
I also discarded your changes to AbstractJdbc3Statement. Those Unicode
mentions are from the interface Javadoc, so I left them alone.
Kris Jurka