* Heikki Linnakangas (hlinnakan...@vmware.com) wrote: > Right. I think Jeff was thinking of a catalog representation for > extensions that haven't been installed yet, but are available in the > system and could be installed with CREATE EXTENSION foo.
I really don't particularly see value in this unless it hooks into PGXN or similar somehow (ala how an apt repository works). I just don't see the point if users have to install templates to then get a list of what extensions they have available to install. The whole 'extension template' piece of this just ends up being overhead and gets in the way. > I wouldn't > mind having a catalog like that. Even without any of this extension > template stuff, it would be handy to have a view that lists all the > extensions available in the filesystem. As mentioned, that's available for the filesystem-based extensions. > There should be no difference between file-based extensions and > catalog-based extensions. It's just two different ways to install > the same extension. The extension author doesn't need to care about > that, it's the DBA that decides which method to use to install it. > > I'm going to object loudly to any proposal that doesn't meet that criteria. Right, which is why I think this is going to *have* to exist outside of the backend as an independent tool which can simply install an extension through normal libpq/PG object creation method- very similar to how extension creation already happens, except that we're being fed from a PG connection instead of reading in an SQL file from the filesystem. Thanks, Stephen
signature.asc
Description: Digital signature