From: | Markus Wanner <markus(at)bluegap(dot)ch> |
---|---|
To: | Hannu Krosing <hannu(at)krosing(dot)net> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Review: extension template |
Date: | 2013-07-08 08:43:16 |
Message-ID: | 51DA7BA4.1000501@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | KONDO Mitsumasa | 2013-07-08 08:45:21 | Re: Improvement of checkpoint IO scheduler for stable transaction responses |
Previous Message | Dimitri Fontaine | 2013-07-08 08:37:42 | Re: [PATCH] Add session_preload_libraries configuration parameter |