Re: ALTER EXTENSION UPGRADE, v3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER EXTENSION UPGRADE, v3
Date: 2011-02-10 21:49:49
Message-ID: 7613.1297374589@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> "David E. Wheeler" <david(at)kineticode(dot)com> writes:
>> Yes, I think that this is a great solution. I only have to create on
>> upgrade script for each release, and I don't have to worry about
>> concatenating anything or be required to change my versioning
>> algorithm.

> You still have to make sure that the C code remains compatible with any
> intermediate release, for the whole life of your extension. But I agree
> that it's way better than what we had before.

What you have to do is make sure the C code remains compatible with any
version you are shipping an install or upgrade script for. Once you
decide that versions before, say, 2.0 are dead as doornails, you remove
all the older scripts, and you can delete the .so infrastructure for
them too.

For example, suppose I have foobar 1.5 installed on my system. If you
are shipping a package that includes foobar-1.5-2.0.sql, I should
reasonably expect that I can install that package first and upgrade the
extension afterwards. If you aren't shipping any script that claims it
can upgrade from 1.5, you don't need to provide .so compatibility either
--- it's clear that I have to upgrade first and install your newer
package after.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2011-02-10 22:08:10 Re: [COMMITTERS] pgsql: Remove more SGML tabs.
Previous Message Aidan Van Dyk 2011-02-10 21:41:47 Re: ALTER EXTENSION UPGRADE, v3