Thread: Testing extension upgrade scripts
It occurred to me that it might be a good idea to describe how
I've been testing extension upgrade scripts. So:
1. Install the 9.0 version of the module in an empty 9.0 database.
pg_dump this database.
2. Load the pg_dump script into an empty 9.1 database, with the
underlying shared library (if any) available in $libdir but not
installed as SQL. (If this fails, probably you removed a C
function from the library.)
3. Execute "CREATE EXTENSION whatever FROM unpackaged;". (If this
fails, obviously you have work to do.)
4. pg_dump --binary-upgrade from the 9.1 database. (You need
--binary-upgrade or pg_dump won't show the member objects of the
extension.)
5. Install the 9.1 version of the extension in another empty
database, using plain "CREATE EXTENSION whatever". Then
pg_dump --binary-upgrade from that.
6. Diff the two 9.1 dump scripts. They should be the same except
for OID and frozenxid numbers. If not, the upgrade script has
missed something it needs to do to update the catalog entries.
Of course, a similar approach will be useful for testing scripts
that are meant to update from one extension version to another,
once we arrive at the point of needing to do that.
regards, tom lane
You should blog this. David On Mar 2, 2011, at 11:58 AM, Tom Lane wrote: > It occurred to me that it might be a good idea to describe how > I've been testing extension upgrade scripts. So: > > 1. Install the 9.0 version of the module in an empty 9.0 database. > pg_dump this database. > > 2. Load the pg_dump script into an empty 9.1 database, with the > underlying shared library (if any) available in $libdir but not > installed as SQL. (If this fails, probably you removed a C > function from the library.) > > 3. Execute "CREATE EXTENSION whatever FROM unpackaged;". (If this > fails, obviously you have work to do.) > > 4. pg_dump --binary-upgrade from the 9.1 database. (You need > --binary-upgrade or pg_dump won't show the member objects of the > extension.) > > 5. Install the 9.1 version of the extension in another empty > database, using plain "CREATE EXTENSION whatever". Then > pg_dump --binary-upgrade from that. > > 6. Diff the two 9.1 dump scripts. They should be the same except > for OID and frozenxid numbers. If not, the upgrade script has > missed something it needs to do to update the catalog entries. > > > Of course, a similar approach will be useful for testing scripts > that are meant to update from one extension version to another, > once we arrive at the point of needing to do that. > > regards, tom lane > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers
"David E. Wheeler" <david@kineticode.com> writes:
> You should blog this.
[ shrug... ] I don't own a blog, and if I did the entries in it would
not be included in the pgsql archives, which is where material like this
probably ought to be.
regards, tom lane
"David E. Wheeler" <david@kineticode.com> writes: > You should blog this. He just did, didn't he? :) Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
david@kineticode.com ("David E. Wheeler") writes:
> You should blog this.
He just did, using the SMTP protocol...
--
select 'cbbrowne' || '@' || 'acm.org';
http://linuxdatabases.info/info/postgresql.html
Where do you want to Tell Microsoft To Go Today?