On Apr 20, 2011, at 8:16 PM, Tom Lane wrote:
> I'm not interested in kluging things up after the fact to try to somehow
> reverse that mindset and make pre-extension-world and post-extension-world
> scripts compatible. That looks like long-term pain in return for very
> small short-term gain to me.
Okay. What about building something into PGXS that could handle these kinds of things? I just can't help but wonder if
thereisn't some better way to do the kinds of things that Daniele and I have resorted to to use a PostgreSQL version in
aconditional in the Makefile. I know *this* much about make, and so am pretty sure that there must be a better way to
doit than the way I am.
> If you have multiple old versions that you want to support direct
> upgrades from, you should *not* use the unvarnished "unpackaged" naming
> convention for those upgrade scripts. Use the real version names
> instead, and instruct the users that they'd better get it right when
> specifying the FROM version. (Or if possible, set up the scripts to
> intentionally fail should they be invoked with the wrong previous
> version in place --- eg, it's not bad if they fail when trying to
> replace an object that's not there.)
Yeah, I was thinking about that, too. It would require a lot of duplication for an extension that doesn't often change,
butin a few years it could be dumped.
> If you did not actually change the contents of the install script, you
> should not change its version number either.
You know what? Duh! I should have thought of that. Glad I made the decision to allow an extension/version combination
toappear in more than one distribution on PGXN. Was kind of a PITA to add, but clearly was the right choice.
Best,
David
