Re: Extension Packaging
David Wheeler <david@kineticode.com>
From: "David E. Wheeler" <david@kineticode.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "pgsql-hackers@postgresql.org Hackers" <pgsql-hackers@postgresql.org>
Date: 2011-04-21T03:25:26Z
Lists: pgsql-hackers
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 there isn't some better way to do the kinds of things that Daniele and I have resorted to to use a PostgreSQL version in a conditional in the Makefile. I know *this* much about make, and so am pretty sure that there must be a better way to do it 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, but in 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 to appear in more than one distribution on PGXN. Was kind of a PITA to add, but clearly was the right choice. Best, David