Josh Berkus <josh@agliodbs.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 |
Administrativefunctions for PostgreSQLpublic | lo | 9.1devel | managing Large Objects
(2 rows)
~:5490=# select oid, * from pg_extension ; oid | extname | extnamespace | relocatable | extversion
-------+-----------+--------------+-------------+------------16385 | lo | 2200 | t |
9.1devel16406| 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.1develpg_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