As Martin Pitt pointed out in this pgsql-bugs thread
http://archives.postgresql.org/pgsql-bugs/2007-10/msg00089.php
we have managed to create an ABI break between 8.2 and 8.3 libpq
by renumbering encoding IDs in pg_wchar.h. Although perhaps this
does not hurt any third-party clients, it does break our own initdb
and psql programs, which turn out to be dependent on libpq and the
backend having the same numbering. Going forward we should try to
fix things so that the exact values of those IDs need not be considered
part of libpq's ABI, but that doesn't get us out of the fact that 8.2
psql will fail if you try to use it with CVS HEAD libpq.so.
It seems that we are faced with a choice of two evils:
1. Accept that there's an ABI break and increment libpq.so's major
version number for 8.3. This will be a PITA for packagers, who will
have to carry a compatibility package to provide 8.2 libpq.so.
2. Renumber 8.3's encoding IDs to preserve compatibility with the
8.2 values. It turns out that we can do that, but we will have to
force initdb because the contents of pg_database.encoding will change.
I'm of the opinion that #2 is the lesser evil, but maybe I'm overly
influenced by my Red Hat packaging responsibilities --- I'll personally
have to spend time on a compatibility package if we go with #1.
Other opinions out there?
Also, if we do #2 it means that we have the option to resolve the
contrib/txid mess by pushing txid into the core backend before beta2.
Any votes pro or con on that?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
