From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, PostgreSQL-Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Extensions, patch v18 (merge against master, bitrot-only-fixes) |
Date: | 2010-12-16 20:43:21 |
Message-ID: | 11852.1292532201@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-12-16 20:49:38 | Re: [PATCH] V3: Idle in transaction cancellation |
Previous Message | Tom Lane | 2010-12-16 20:41:10 | Re: [PATCH] V3: Idle in transaction cancellation |