Re: Review: extension template

From: Hannu Krosing <hannu(at)krosing(dot)net>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Markus Wanner <markus(at)bluegap(dot)ch>, Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Review: extension template
Date: 2013-06-10 19:43:08
Message-ID: 51B62C4C.5000108@krosing.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2013-06-10 19:45:02 Re: DO ... RETURNING
Previous Message David Fetter 2013-06-10 19:34:47 Re: DO ... RETURNING