Re: Extension Packaging
От | David E. Wheeler |
---|---|
Тема | Re: Extension Packaging |
Дата | |
Msg-id | 20B3CD7F-9CB0-4DCA-B3DF-68CC146F9179@kineticode.com обсуждение исходный текст |
Ответ на | Re: Extension Packaging (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Extension Packaging
|
Список | 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 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
В списке pgsql-hackers по дате отправления: