Alvaro Herrera <alvhe...@commandprompt.com> writes:
> 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.
Right, they would have to be decoupled if you believe what I said above.
> 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.
It would be tolerable, if perhaps error-prone. But we've seldom blown
it on catversion, and this would be a comparable requirement.
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
