Re: Review: extension template - Mailing list pgsql-hackers

From Markus Wanner
Subject Re: Review: extension template
Date
Msg-id 51DA7BA4.1000501@bluegap.ch
Whole thread Raw
In response to Re: Review: extension template  (Hannu Krosing <hannu@krosing.net>)
List pgsql-hackers
On 06/10/2013 09:43 PM, Hannu Krosing wrote:
> On 07/08/2013 09:26 AM, Heikki Linnakangas wrote:
>> 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.

Remember that we already have quite a lot of extensions. And PGXN. Are
we really so wedded to the idea of extensions "living" outside of the
database that we need to come up with something different and incompatible?

Or do you envision modules or packages to be compatible with extensions?
Just putting another label on it so we can still claim extensions are
strictly external to the database? Sorry, I don't get the idea, there.

From a users perspective, I want extensions, modules, or packages to be
managed somehow. Including upgrades, migrations (i.e. dump & restore)
and removal. The approach of letting the distributors handle that
packaging clearly has its limitations. What's so terribly wrong with
Postgres itself providing better tools to manage those?

Inventing yet another type of extension, module or package (compatible
or not) doesn't help, but increases confusion even further. Or how do
you explain to an author of an existing extension, whether or not he
should convert his extension to a module (if you want those to be
incompatible)?

If it's the same thing, just with different loading mechanisms, please
keep calling it the same: an extension. (And maintain compatibility
between the different ways to load it.)

I fully agree with the fundamental direction of Dimitri's patch. I think
Postgres needs to better manage its extensions itself. Including dump
and restore cycles. However, I think the implementation isn't optimal,
yet. I pointed out a few usability issues and gave reasons why
"template" is a misnomer (with the proposed implementation). "Extension"
is not.

(I still think "template" would be a good mental model. See my other
thread...
http://archives.postgresql.org/message-id/51D72C1D.7010609@bluegap.ch)

Regards

Markus Wanner



pgsql-hackers by date:

Previous
From: KONDO Mitsumasa
Date:
Subject: Re: Improvement of checkpoint IO scheduler for stable transaction responses
Next
From: Dimitri Fontaine
Date:
Subject: Re: in-catalog Extension Scripts and Control parameters (templates?)