Re: ALTER EXTENSION UPGRADE, v3

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> How *are* we detecting which version is installed, anyway? Is that in
> the pg_extenstions table?

The installed version is in the pg_extenstion catalog, the version we're
upgrading to is in the control file and can be seen in the system view
pg_available_extensions or from the system SRF named the same:

~:5490=# \dx
List of extensions
Schema | Name | Version | Description
------------+-----------+----------+-----------------------------------------
pg_catalog | adminpack | 9.1devel | Administrative functions for PostgreSQL
public | lo | 9.1devel | managing Large Objects
(2 rows)

~:5490=# select oid, * from pg_extension ;
oid | extname | extnamespace | relocatable | extversion
-------+-----------+--------------+-------------+------------
16385 | lo | 2200 | t | 9.1devel
16406 | adminpack | 11 | f | 9.1devel
(2 rows)

~:5490=# select schema, name, installed, version from pg_available_extensions limit 10;
schema | name | installed | version
------------+--------------------+-----------+----------
public | lo | 9.1devel | 9.1devel
pg_catalog | adminpack | 9.1devel | 9.1devel
| citext | | 9.1devel
| chkpass | | 9.1devel
| cube | | 9.1devel
| pg_stat_statements | | 9.1devel
| pg_buffercache | | 9.1devel
| dict_xsyn | | 9.1devel
| earthdistance | | 9.1devel
| xml2 | | 9.1devel
(10 rows)

> So every package would include a script called upgrade.sql ( or
> upgrade.c? ) which is supposed to handle the upgrade, and it's up to the
> module author to power that, at least until 9.2? Seem like the most
> reasonable course for February ...

Yeah. Of course you want to support shipping upgrade files for more
than one upgrade situation, that's in my proposal and patch too. The
extension author "just" have to fill in the control file with an upgrade
setup: regexp against installed version string => upgrade script to
use. And that's about it.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support