On 18/04/11 15:57, Tom Lane wrote:
> Bernd Helmle<mailings@oopsware.de> writes:
>> If i am reading it correct, it reads "UTF8" from the backend, while
>> expecting "UNICODE" only. Not sure what change has caused this,
>> though.
> I am --- when I redid the GUC assign_hook logic a few weeks ago,
> I changed the client_encoding code so that it shows the normalized
> (official) name of the encoding, not whatever random string the client
> sent over. For instance, previous versions:
>
> regression=# set client_encoding = 'UnIcOdE';
> SET
> regression=# show client_encoding ;
> client_encoding
> -----------------
> UnIcOdE
> (1 row)
>
> versus HEAD:
>
> regression=# set client_encoding = 'UnIcOdE';
> SET
> regression=# show client_encoding ;
> client_encoding
> -----------------
> UTF8
> (1 row)
>
> I wasn't aware that JDBC would fail on that. It's pretty annoying that
> it does, but maybe we should grin and bear it, ie revert the change to
> canonicalize the GUC's value?
>
> regards, tom lane
>
Am I right in thinking that would be that change committed on the 7th
(http://archives.postgresql.org/pgsql-committers/2011-04/msg00039.php) ?
I've just run the JDBC test build on my machine and it fails dismally
with this very message repeated over and over again. What concerns me
most is that (assuming my dates are right) the JDBC driver has been
broken for 11 days and no one noticed. This would lead me to believe
that there is no JDBC build server. What would it take to set one up? If
someone can point me to a test machine I'd happily assist in setting one up.
As for the breakage itself I'm OK with a new driver version for a new
database version and from my experience people expect that. I recall a
number of people asking me if an 8.4 driver would be OK to use against 9
before the 9 version was stable.
Regards,
--
Mike Fowler
Registered Linux user: 379787