Re: 7.2.x -> 7.3 upgrade docs?

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?

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.

_Basically_ a Perl application using DBD::Pg with 7.3 should work out of the
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
that.

> 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´ve just upgraded a mod_perl/DBD::Pg application to
PostgreSQL 7.3 and have not encountered any DBD::Pg-related problems. The
application doesn't know about schemas yet though (all objects are in the
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?

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(at)gmx(dot)net