Re: Extension Templates S03E11

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> Without that, all of the information about a given extension is already in
> the database in our dependency system. As you pointed out, there was

That's not entirely true. We would still be missing some information
from the extension control file.

> previously a notion of "inline" templates. I'm not sure that particular
> patch is exactly where we want to go, but I absolutely do not like this
> idea that we have a "template" on a per-database level which does nothing
> but duplicate most of the information we *already have*, since you have to
> assume that if the extension template (which is per-database) exists then
> the extension has also been created in the database.

That's a classic bootstrap problem. If you consider that the extension
is already installed, then you don't need to know how to install it.

The main feature that the patch provides is installation path for an
extension that doesn't involve the server's file system.

> Having a versioning notion (and whatever other meta data we, or an
> extension author, feels is useful) for what are otherwise simple containers
> (aka the schematic we already have..) makes sense and it would be great to
> provide support around that, but not this duplication of
> object definitions.

I don't like duplication either, we've just been failing to find any
alternative with pg_restore support for the last 3 years.

If you want the simplest possible patch that would enable you bypassing
the file system, here's what I would be proposing: have a special flag
allowing CREATE EXTENSION to just prepare pg_extension catalog entries.

Then create your objects as usual, and use ALTER EXTENSION … ADD … to
register them against the existing extension.

That would work beautifully, and of course you would have to do that
again manually at pg_restore time after CREATE DATABASE and before
pg_restore, or you would need to change the fact that extensions objects
are not part of your pg_dump scripts, or you would have to name your new
thing something else than an extension.

Also, please note that I did propose that design when working on the
first patch series for extension (8.4 and 9.0 eras), or at least some
variant where the control properties came in from some command rather
than from a file, and it was rejected because the CREATE EXTENSION
bootstrapping was then judged too complex, and it was not clear how
extension authors were going to maintain their scripts.

The current extension model is simple enough to reason about. A script
must be provided in a template and is executed at CREATE EXTENSION time
or at ALTER EXTENSION UPDATE time, and pg_dump only contains the CREATE
EXTENSION command, so that pg_restore has to find the template again.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support