Re: Extension Templates S03E11

On Sun, 2013-12-01 at 22:34 -0500, Stephen Frost wrote:
> Perhaps I'm missing something- but we already *have* a catalog
> representation for every extension that's ever installed into a given
> database.  A representation that's a heck of a lot better than a big
> text blob.

I meant "extension template" represented in the catalog.

> > But bringing more of an extension into the catalog can be done, and I
> > think we'll see big benefits from that.
> 
> I'm not following here- what's 'missing'?

It seems that you are making the assumption that installing an extension
template or creating an extension are major operations, and anyone
encountering an error is a superuser with admin access to the server and
can easily correct it.

If the admin messes up and the extension template isn't there (e.g.
after a failover), the person to encounter the error at CREATE EXTENSION
time might not have admin access or there might be a process required to
deploy the new files. But if the extension templates were carried along
with replication and backup naturally, then they'd be there.

And it would be nice if there was some hope for non-superusers to create
extension templates, but that will never happen as long as they are
files.

> > That being said, there some things about in-catalog templates that need
> > some more thought:
> > 
> >   1. If someone does want their OS to install extensions for them (e.g.
> > the contrib package), how should that be done? This usually works fine
> > with the aforementioned languages, because installation is still just
> > dropping files in the right place. Postgres is different, because to put
> > something in the catalog, we need a running server, which is awkward for
> > a packaging system to do.
> 
> You need a running PG for the *extension* to be installed, but with the
> filesystem-based extension approach we have today, the "template" (which
> are the files on the filesystem) don't need PG running

I think you misread -- this is a list of issues if we move templates
into the catalog. File-based templates obviously don't have this
problem.

> >   3. What do we do about native shared libraries? Ultimately, I imagine
> > that we should handle these similarly to tablespaces: have a real
> > database object with an OID that extensions or functions can depend on,
> > and create a symlink (with the OID as the link name) that points to the
> > real file on disk. We could also export some new symbols like the shared
> > library name and version for better error checking.
> 
> I'm sorry, but I do not see shared libraries working through this
> system, at all.  I know that goes against what Dimitri and some others
> want, but I've talked with a few folks (such as Paul Ramsey of PostGIS)
> about this notion and, from that perspective, it's almost laughable to
> think we could ship shared libraries in this way.  Even if we could
> convince ourselves that there's some way for us to track the files on
> the filesystem and work out all the per-database and whatever issues are
> associated with that, it'd only work for the simplest shared libraries
> which don't have any dependencies on other libraries on the system
> (excepting, perhaps, libc6) and that narrows the use-case down
> significantly, to the point where I don't feel it's worth all that
> effort.

I was just suggesting that a little more information in the catalog
could improve dependency tracking and error handling. I'm not suggesting
we "ship" any shared libraries anywhere -- that's still up to extension
authors and PGXN. I'm also not suggesting that the error handling will
be perfect or catch subtle mismatches.

Regards,Jeff Davis