* Heikki Linnakangas (hlinnakangas@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