Re: libpq5 8.3 breaks 8.2 compatibility with encodings

Hi,

Tom Lane [2007-10-12 12:02 -0400]:
> Does anything other than initdb get weird?

It's hard to tell, my test suite concentrates on hammering initdbs
with various locales, encodings, getting a chain of 7.4->8.{0,1,2,3}
upgrades and testing the conversion of postgresql.conf arguments, etc.
I do not do that much of locale juggling (only some particular tests
to check for the infamous CVE-2006-2313/4).

I'm just afraid there might be other lurking regressions. I can do
some tests with psql and set client_encoding, etc.

> For the most part I believe it's the case that libpq's idea of the enum
> values is independent of the backend's. I think the issue here is that
> initdb is (mis) using libpq's pg_char_to_encoding, etc, and combining
> those functions with its own idea of the meanings of the enum values.
>
> Maybe we should stop exporting pg_char_to_encoding and so on from libpq,
> though I wonder if that would break any clients.

Hm, at least that sounds like a good method to find out what other
parts of the code use this array directly.

Thanks,

Martin

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