On Mon, 18 Apr 2011, Mike Fowler wrote:
On 18/04/11 17:12, Tom Lane wrote:
Dave Cramer<p...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
