libpq5 8.3 breaks 8.2 compatibility with encodings

Hi PostgreSQL developers,

I'm currently hunting down the last postgresql-common test case
failure that I see with 8.3beta1. It seems the 8.3 version of libpq
changes some internal encoding lists?

If I use the 8.2 programs with the 8.2 library, all is well:

  $ LC_ALL=3Den_US.UTF-8 /usr/lib/postgresql/8.2/bin/initdb --encoding UTF8=
 -D /tmp/x
  [...]
  The database cluster will be initialized with locale en_US.UTF-8.
  [...]
  $ /usr/lib/postgresql/8.2/bin/postgres -D /tmp/x -k /tmp &
  $ /usr/lib/postgresql/8.2/bin/psql -Alth /tmp
  postgres|martin|UTF8
  template0|martin|UTF8
  template1|martin|UTF8

However, if I use 8.2 programs with the 8.3 library, things start to
become weird:

  $ # kill postgres instance
  $ rm -rf /tmp/x; LC_ALL=3Den_US.UTF-8 /usr/lib/postgresql/8.2/bin/initdb =
--encoding UTF8 -D /tmp/x
  [...]
  The database cluster will be initialized with locale en_US.UTF-8.
  initdb: warning: encoding mismatch
  The encoding you selected (UTF8) and the encoding that the selected
  locale uses (UTF-8) are not known to match.  This may lead to
  misbehavior in various character string processing functions.  To fix
  this situation, rerun initdb and either do not specify an encoding
  explicitly, or choose a matching combination.
  [...]
  $ /usr/lib/postgresql/8.2/bin/postgres -D /tmp/x -k /tmp &
  $ /usr/lib/postgresql/8.2/bin/psql -Alth /tmp
  postgres|martin|JOHAB
  template0|martin|JOHAB
  template1|martin|JOHAB

In the latter configuration, when I do not explicitly specify an
encoding, the initdb output still looks weird, but at least the
result seems to be correct:

  $ rm -rf /tmp/x; LC_ALL=3Den_US.UTF-8 /usr/lib/postgresql/8.2/bin/initdb =
-D /tmp/x
  [...]
  The database cluster will be initialized with locale en_US.UTF-8.
  The default database encoding has accordingly been set to MULE_INTERNAL.
  [...]
  $ /usr/lib/postgresql/8.2/bin/postgres -D /tmp/x -k /tmp &
  $ /usr/lib/postgresql/8.2/bin/psql -Alth /tmp
  postgres|martin|UTF8
  template0|martin|UTF8
  template1|martin|UTF8

This is a bit unfortunate, since it breaks ABI compatibility without
announcing it in the SONAME. From the previous discussion it is quite
clear that a soname bump is a pain, so could this be changed somehow
to accomodate new encodings while remaining binary compatibility with
earlier releases?

Thanks,

Martin
--=20
Martin Pitt        http://www.piware.de
Ubuntu Developer   http://www.ubuntu.com
Debian Developer   http://www.debian.org