Content-Type: text/plain;
  charset="iso-8859-1"
From: Ian Barwick <barwick@gmx.net>
To: "Thomas O'Connell" <tfo@monsterlabs.com>,
	pgsql-admin@postgresql.org, pgsql-docs@postgresql.org,
	pgsql-general@postgresql.org
Subject: Re: 7.2.x -> 7.3 upgrade docs?
Date: Wed, 11 Dec 2002 23:25:56 +0100
References: <tfo-44E9FD.14432711122002@news.hub.org>
In-Reply-To: <tfo-44E9FD.14432711122002@news.hub.org>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200212112325.56961.barwick@gmx.net>

On Wednesday 11 December 2002 21:43, Thomas O'Connell wrote:
> has anyone put together a Sensible Strategies for Upgrading document
> when moving from 7.2.x to 7.3?

Some replies to some of your questions:

> 2. is it necessary, strongly recommended, recommended, or irrelevant to
> upgrade DBD::Pg for people accessing postgres via the Perl DBI?=20

Short answer: no urgent need.
Long answer: Unfortunately DBD::Pg is "out of sync" with the PostgreSQL
release process and hasn't yet been upgraded to take into account of
the changes in 7.3.=20

_Basically_ a Perl application using DBD::Pg  with 7.3 should work out of t=
he
box if you retain all objects in the default PUBLIC schema; AFAICS there are
no problems using other schemas; where you may run into problems is with
DBD::Pg functions querying database meta-data (anything that accesses the
system catalogs). Definitively broken is the DBD::Pg-specific function
"table_attributes", though I am in the process of submitting a patch to fix=
=20
that.=20

> speaking
> of which, are there docs about what changed in the latest DBD::Pg?

The latest DBD::Pg (v1.20) includes a "Changes" file.
I haven't seen anything specific on using it with PostgreSQL 7.3. I've
run into the same issue myself and have a draft commentary and
possibly some further patches which I'll make available ASAP.

On a practical note: I=B4ve just upgraded a mod_perl/DBD::Pg application to=
=20
PostgreSQL 7.3 and have not encountered any DBD::Pg-related problems. The=
=20
application doesn't know about schemas yet though (all objects are in the=
=20
default PUBLIC schema).

> 3. what is the default environment as far as schemas are concerned for
> databases that have been migrated? is there just a public schema created
> for all objects?=20

A typical dump/restore puts everything in the default PUBLIC schema.

> is it possible to move existing tables into
> user-created schemas? i didn't see an ALTER TABLE SET SCHEMA...

I don't think so; you may need to manually alter the pg_dump files
before restoring. Maybe someone more knowledgable will come up with
a more qualified answer.

> 4. are there other important considerations i might be overlooking?

I would recommend thorough testing before you commit to an upgrade ;-)

Ian Barwick
barwick@gmx.net