> Well if you want to support upgrades between each two versions, that
> means you have users and you don't know what they currently have
> installed. Then you have this problem to solve, and it's complex the
> same no matter what tools are offered.
How *are* we detecting which version is installed, anyway? Is that in
the pg_extenstions table?
> You're missing something here. In this scheme, make is only used to
> prepare the upgrade scripts. Then you package and ship those, and you
> don't need make no more, even when the target is windows. More than
> that, the tool to use would be `cat`, really, Make would just call it on
> files in the right order. A perl one-liner will certainly do just fine.
Ah, I see. So you're proposing a build system for the 100's of
verison-to-version upgrade scripts. That makes a lot more sense,
although I wonder what such a build script would look like in actuality.
> Agreed. So my proposal was, again, that we don't solve it this year but
> provide a mechanism that allows extension authors to setup which script
> to run when the user will ALTER EXTENSION foo UPGRADE. How they come up
> with such a script, I say, is *NOT* our problem. At least for 9.1.
So every package would include a script called upgrade.sql ( or
upgrade.c? ) which is supposed to handle the upgrade, and it's up to the
module author to power that, at least until 9.2? Seem like the most
reasonable course for February ...
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
