> 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
peoplewho 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
