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:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Review: extension template
Next
From: Heikki Linnakangas
Date:
Subject: Re: XLogInsert scaling, revisited