"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> 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?
I'd like to get the locale/encoding issues straightened out, and also
get the contrib-tsearch-examples st
> 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
Hi,
On Fri, 2007-10-12 at 18:41 -0400, Tom Lane wrote:
>
> 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?
On Oct 12, 2007, at 17:41 , Tom Lane wrote:
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?
+1
Michael Glaesemann
grzm seespotcode net
---(end of b
On Friday 12 October 2007 15:41:58 Tom Lane wrote:
> 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 perhap
Tom Lane wrote:
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 opti
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
