Re: libpq5 8.3 breaks 8.2 compatibility with encodings - Mailing list pgsql-bugs

From Martin Pitt
Subject Re: libpq5 8.3 breaks 8.2 compatibility with encodings
Date
Msg-id 20071012170819.GL5911@piware.de
Whole thread Raw
In response to Re: libpq5 8.3 breaks 8.2 compatibility with encodings  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #3674: Unnecessary checkpoints by WAL Writer
Next
From: "Heikki Linnakangas"
Date:
Subject: Re: libpq5 8.3 breaks 8.2 compatibility with encodings