Stephen Frost <sfr...@snowman.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
