Seems we need a post-beta1 initdb already

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 option to resolve the
contrib/txid mess by pushing txid into the core backend before beta2.
Any votes pro or con on that?

#2 by all means. Post-beta initdb is mildly unfortunate; compatibility
packages are to be avoided far more.

+1 to put txid in core, where it belongs.

cheers

andrew

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

I vote that adding txid to the backend now will be of better value for all
parties involved than not, given it's coming without any particular pain.
(though I may be a bit biased on this). By having it in core it's one less
thing that skytools/slony needs to detect and error out on with an message
saying install contrib/txid during their install phases. Not to mention this
puts having replication that much more likely to be available in shared
hosting environments who by all reports loth installing contrib for their
customers.

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

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?

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?

I am also for #2 (and yes, I want to avoid yet another compat rpm
problem...)

Regards,
--
Devrim GÜNDÜZ
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/

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

"Magnus Hagander" <magnus@hagander.net> 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 stuff in, before we think about beta2.
But hopefully that won't take very long.

regards, tom lane