> 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?
#2 seems like a much better choice. A small inconvenience during beta is much
better than one in the actual release.
People running the beta expects us to try not to force initdb, but also that
we'll do it if we have to.
Might be worthwhile to try to get beta2 out as quickly as we can after the
changes are in, to minimize the number of people who will need it?
> 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?
Absolutely pro.
/Magnus
---------------------------(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
