Re: [JDBC] JDBC connections to 9.1
От | Kris Jurka |
---|---|
Тема | Re: [JDBC] JDBC connections to 9.1 |
Дата | |
Msg-id | alpine.BSO.2.00.1104182115350.27592@leary.csoft.net обсуждение исходный текст |
Ответ на | Re: [JDBC] JDBC connections to 9.1 (Mike Fowler <mike@mlfowler.com>) |
Ответы |
Re: [JDBC] JDBC connections to 9.1
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: