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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
