Re: libpq5 8.3 breaks 8.2 compatibility with encodings

OK, I spent some time analyzing this problem, and I think there's a
fairly simple way to avoid a libpq ABI break between 8.2 and 8.3.
Although we removed PG_JOHAB as a backend encoding, we added
PG_EUC_JIS_2004.  Therefore, if we rearrange things to give
PG_EUC_JIS_2004 the old number of PG_JOHAB, and make sure that PG_JOHAB
and the other new frontend-only encodings are at the end, we will have
numerical compatibility for everything except PG_JOHAB itself --- and
even there the only apparent discrepancy will be in whether
pg_valid_server_encoding thinks it's a backend encoding or not.
(An 8.3 libpq will correctly report that it's not, where 8.2 thought
it was.)  So this seems about as close as we can reasonably get.

Moving forward, we definitely want to decouple the libpq and backend
interpretations of the encoding enum so that we won't get burnt like
this again.  I propose that we fix things so that henceforth no libpq
client is expected to import pg_wchar.h, and therefore can't have any
hardwired knowledge of the meaning of any given encoding number.
This would primarily mean acknowledging pg_encoding_to_char,
pg_char_to_encoding, and pg_valid_server_encoding as official parts of
libpq's API, by declaring them in libpq-fe.h.  I'd also want to fix
initdb so that it doesn't link to libpq.so at all, but compiles its own
copies of the necessary files, thereby ensuring that its numbering is
compatible with chklocale.c (which is also statically linked into
initdb) and with the matching postgres executable.

The remaining stumbling block is psql/mbprint.c, which among other
nastiness has compiled-in dependencies on the numerical value of
PG_UTF8.  I'm of the opinion that that entire file is misconceived;
at the very least it needs to be moved someplace else.  That however
is more work than I want to tackle for 8.3 --- for one thing, the only
obvious place to put it is libpq.so, which we couldn't do without a
soname bump.  So what I propose doing for now is allowing it to continue
to depend on pg_wchar.h, and inserting into the latter a caution that
PG_UTF8 mustn't be renumbered until the mbprint situation is cleaned up.

Comments, better ideas?

            regards, tom lane