Thread: "Extension" versus "module"
Appendix F (contrib.sgml and its subsidiary files) is pretty consistent
about using "module" to refer to a contrib, uh, module.
I considered doing a search-and-replace to change this to "extension",
but I'm not convinced that's a good idea. I think "extension" means a
specific kind of SQL object that we just invented, and it's not exactly
the same concept as "one of those subdirectories under contrib/". One
pretty obvious example is that contrib/spi calls itself a module, and
it's definitely not an extension --- it contains five extensions, none
of them named "spi". Another problem is that we'd like to speak of
upgrading a module from pre-9.1 to 9.1, and in only one of those two
states is it strictly correct to call it an "extension". But in some
sense it's still the same entity.
So I'm not sure whether to change the text at all. Comments?
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > Appendix F (contrib.sgml and its subsidiary files) is pretty consistent > about using "module" to refer to a contrib, uh, module. I'm now thinking in those terms: the module is the shared object library that the backend needs to dlopen(). The extension is the SQL level object that wraps all its components. > I considered doing a search-and-replace to change this to "extension", > but I'm not convinced that's a good idea. I think "extension" means a > specific kind of SQL object that we just invented, and it's not exactly > the same concept as "one of those subdirectories under contrib/". One > pretty obvious example is that contrib/spi calls itself a module, and > it's definitely not an extension --- it contains five extensions, none > of them named "spi". Another problem is that we'd like to speak of > upgrading a module from pre-9.1 to 9.1, and in only one of those two > states is it strictly correct to call it an "extension". But in some > sense it's still the same entity. > > So I'm not sure whether to change the text at all. Comments? +1 -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Appendix F (contrib.sgml and its subsidiary files) is pretty consistent
>> about using "module" to refer to a contrib, uh, module.
> I'm now thinking in those terms: the module is the shared object library
> that the backend needs to dlopen(). The extension is the SQL level
> object that wraps all its components.
Hmm ... but what of contrib "modules" that don't build shared libraries
at all --- pgbench and pg_upgrade for example?
I think "shared library" is a perfectly fine term for that kind of
object, and we don't need an alias for it anyway.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > Hmm ... but what of contrib "modules" that don't build shared libraries > at all --- pgbench and pg_upgrade for example? > > I think "shared library" is a perfectly fine term for that kind of > object, and we don't need an alias for it anyway. In my view, if there's no script, that is no SQL object to install in a database, then it's not an extension. I would think that we keep the directory named contrib for them. Then, an extension can be implemented partly with a module, coded in C, installed as a shared library. Another concern has to do with PLs. We said that with the dependency mechanism it would be good to have PLs be EXTENSIONs. But those are core provided extensions, one of them installed by default. If we make PLs extensions, we might also want to have CREATE LANGUAGE either ERROR out or silently do the CREATE EXTENSION instead, meaning that CREATE LANGUAGE behavior would depend on creating_extension. Sounds like a crock but ensures compatibility. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Another concern has to do with PLs. We said that with the dependency
> mechanism it would be good to have PLs be EXTENSIONs. But those are
> core provided extensions, one of them installed by default.
> If we make PLs extensions, we might also want to have CREATE LANGUAGE
> either ERROR out or silently do the CREATE EXTENSION instead, meaning
> that CREATE LANGUAGE behavior would depend on creating_extension.
> Sounds like a crock but ensures compatibility.
Yeah. I was sort of wondering whether we could get rid of pg_pltemplate
altogether, and instead rely on the extension mechanism to package up
the correct parameters for installing a language. However, one thing
that'd have to be solved before going very far in this direction is the
question of allowing CREATE EXTENSION to non-superusers. We'd at least
need to be able to duplicate the current functionality of allowing
CREATE LANGUAGE to database owners (with an override available to the
DBA).
This seems like a matter for a separate thread though, and not on
pgsql-docs.
regards, tom lane
On Mon, 2011-02-14 at 12:48 +0100, Dimitri Fontaine wrote: > Tom Lane <tgl@sss.pgh.pa.us> writes: > > Appendix F (contrib.sgml and its subsidiary files) is pretty consistent > > about using "module" to refer to a contrib, uh, module. > > I'm now thinking in those terms: the module is the shared object library > that the backend needs to dlopen(). The extension is the SQL level > object that wraps all its components. I would say that some modules are extensions, but not all. A standalone executable might be part of a module, but would not be an extension. Remember also that not all modules out there on the net will have been updated either, so we must be able to discuss "extension-izing a module". (??) -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services
Simon Riggs <simon@2ndQuadrant.com> writes:
> I would say that some modules are extensions, but not all. A standalone
> executable might be part of a module, but would not be an extension.
> Remember also that not all modules out there on the net will have been
> updated either, so we must be able to discuss "extension-izing a
> module". (??)
Right. So it seems like we ought to stick with more or less the
existing terminology: those various components under contrib/ are
modules. Some of them are also extensions, but not all.
regards, tom lane
On Feb 14, 2011, at 5:42 PM, Tom Lane wrote: >> Remember also that not all modules out there on the net will have been >> updated either, so we must be able to discuss "extension-izing a >> module". (??) > > Right. So it seems like we ought to stick with more or less the > existing terminology: those various components under contrib/ are > modules. Some of them are also extensions, but not all. The similarity of the meaning of the words "extension" and "module" is unfortunate, as it might be hard for one to rememberwhich is which. But given the precedent of the word "module," I don't suppose there's much choice. Best, David