Re: Extensions, patch v18 (merge against master, bitrot-only-fixes)

Excerpts from Tom Lane's message of jue dic 16 17:10:10 -0300 2010:

> However, the only way I can see to fix this "automatically" is to have
> the makefiles propagate PG_VERSION_NUM (or one of the other values set
> by configure) into generated control files. I don't think that's what
> we want either. If we do that, then people are going to be forced to
> go through an ALTER EXTENSION UPGRADE cycle whether or not anything
> actually changed in the extension's SQL definitions. We really only
> want the extension's SQL version to change when there was a meaningful
> change in the SQL commands.

I've been wondering if we should stop thinking that each contrib's
module version is the same as the backend version. What if we declare
them all 1.0.0 for the 9.1 release, and increment the version manually
each time there's a change? So a module that stays unchanged for 9.2
would still be 1.0.0. (The .so file would still need to be recompiled
for the new server version, because of PG_MODULE_MAGIC.)

In that case, having hand-maintained version numbers in control or
wherever is not so much of a problem; the committer that touches the
module needs to ensure that the version number is incremented too.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support