Re: [DOCS] [HACKERS] "Extension" versus "module"
Dimitri Fontaine writes: > Tom Lane 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 -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Building PDFs error: \pdfendlink ended up in different nesting level than \pd
Excerpts from Peter Eisentraut's message of sáb feb 12 04:44:10 -0300 2011: > With the promotion of the contrib stuff, perhaps they should each get > their own chapter in a new part. +1 to this idea. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [HACKERS] "Extension" versus "module"
Dimitri Fontaine 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 -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [HACKERS] "Extension" versus "module"
Tom Lane 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 -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [HACKERS] "Extension" versus "module"
Tom Lane 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 -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [HACKERS] "Extension" versus "module"
On Mon, 2011-02-14 at 12:48 +0100, Dimitri Fontaine wrote: > Tom Lane 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 -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [HACKERS] "Extension" versus "module"
Simon Riggs 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 -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [HACKERS] "Extension" versus "module"
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 remember which is which. But given the precedent of the word "module," I don't suppose there's much choice. Best, David -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
