Dimitri Fontaine <dimi...@2ndquadrant.fr> writes:
> "David E. Wheeler" <da...@kineticode.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
