Re: Review: extension template - Mailing list pgsql-hackers
From | Hannu Krosing |
---|---|
Subject | Re: Review: extension template |
Date | |
Msg-id | 51B62C4C.5000108@krosing.net Whole thread Raw |
In response to | Re: Review: extension template (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Responses |
Re: Review: extension template
Re: Review: extension template |
List | pgsql-hackers |
On 07/08/2013 09:26 AM, Heikki Linnakangas wrote: > On 08.07.2013 00:48, Markus Wanner wrote: >> On 07/07/2013 09:51 PM, Dimitri Fontaine wrote: >>> The design we found to address that is >>> called "Extension Templates" and is implemented in the current patch. >> >> I placed my concerns with the proposed implementation. It's certainly >> not the only way how Postgres can manage its extensions. And I still >> hope we can come up with something that's simpler to use and easier to >> understand. > > I'm just now dabbling back to this thread after skipping a lot of > discussion, and I'm disappointed to see that this still seems to be > running in circles on the same basic question: What exactly is the > patch trying to accomplish. > > The whole point of extensions, as they were originally implemented, is > to allow them to be managed *outside* the database. In particular, > they are not included in pg_dump. If you do want them to be included > in pg_dump, why create it as an extension in the first place? Why not > just run the create script and create the functions, datatypes etc. > directly, like you always did before extensions were even invented. > > I think the reason is that extensions provide some handy packaging of > the functions etc, so that you can just do "DROP EXTENSION foo" to get > rid of all of them. Also, pg_extension table keeps track of the > currently installed version. Perhaps we need to step back and invent > another concept that is totally separate from extensions, to provide > those features. Let's call them "modules". A module is like an > extension, in that all the objects in the module can be dropped with a > simple "DROP MODULE foo" command. To create a module, you run "CREATE > MODULE foo AS <SQL script to create the objects in the module>". > > I believe that would be pretty much exactly what Dimitri's original > inline extension patches did, except that it's not called an > extension, but a module. I think it's largely been the naming that has > been the problem with this patch from the very beginning. We came up > with the concept of templates after we had decided that the originally > proposed behavior was not what we want from something called > extensions. But if you rewind to the very beginning, the problem was > just with the name. The concept was useful, but not something we want > to call an extension, because the distinguishing feature of an > extension is that it lives outside the database and is *not* included > in pg_dump. Either MODULE or PACKAGE would be good name candidates. Still, getting this functionality in seems more important than exact naming, though naming them "right" would be nice. > > - Heikki > >
pgsql-hackers by date: