* Jeff Davis (pg...@j-davis.com) wrote: > On Wed, 2013-12-04 at 14:54 -0500, Tom Lane wrote: > > I think Stephen has already argued why it could be a good idea here. > > But in a nutshell: it seems like there are two use-cases to be > > supported, one where you want "CREATE EXTENSION hstore" to give you > > some appropriate version of hstore, and one where you want to restore > > exactly what you had on the previous installation. It seems to me that > > "exploding" the extension by dumping, rather than suppressing, its > > component objects is by far the most reliable way of accomplishing the > > latter. > > The behavior of an extension should not depend on how it was installed. > > The kind of "extension" being described by Stephen will: > > * Not be updatable by doing "ALTER EXTENSION foo UPDATE TO '2.0'"
That's correct, but consider when the above command actually works today: when the new version is magically made available to the backend without any action happening in PG. That works when the filesystem can be updated independently or the backend can reach out to some other place and pull things down but that's, really, a pretty special situation. It works today specifically because we expect the OS packaging system to make changes to the filesystem for us but this whole 'extension template' proposal is about getting away from the filesystem. Instead, I'm suggesting an external tool which can pull down the new version from an external repo and then apply it to the backend. Clearly, my approach supports the general action of updating an extension, it just doesn't expect the filesystem on the server to be changed underneath PG nor that PG will reach out to some external repository on the basis of a non-superuser request to get the update script. > * Dump out objects that wouldn't be dumped if they had installed the > extension using the filesystem Correct, but the general presumption here is that many of these "extensions" wouldn't even be available for installation on the filesystem anyway. > So if we do it this way, then we should pick a new name, like "package". I've been on the fence about this for a while. There's definitely pros and cons to consider but it would go very much against one of the goals here, which is to avoid asking extension authors (or their users, to some extent..) to change and I expect it'd also be a lot more work to invent something which is 90% the same as extensions. Perhaps there's no help for it and we'll need "extensions" which are essentially for OS managed extensions (which can include .so files and friends) and then "packages" for entirely-in-catalog sets of objects with a certain amount of metadata included (version and the like). > And then we'll need to decide whether it still makes sense to use an > external tool to transform a PGXN extension into a form that could be > loaded as a package. I'd certainly think it would be but if we're moving away from calling them extensions then I'm afraid extension authors and users would end up having to change something anyway, no matter the tool. Perhaps that's reasonable and we can at least minimize the impact but much of what extensions offer are, in fact, what's also needed for packages and I'm not thrilled with the apparent duplication. It just occured to me that perhaps we can "call" these something different towards the end user but use the existing catalogs and code for extensions to handle our representation, with a few minor tweaks.. Not sure if I like that idea, but it's a thought. Thanks, Stephen
Description: Digital signature