Re: [HACKERS] Extension versus module
Tom Lane t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extension versus module
Dimitri Fontaine dimi...@2ndquadrant.fr writes: Tom Lane t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extension versus module
Tom Lane t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extension versus module
Dimitri Fontaine dimi...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extension versus module
On Mon, 2011-02-14 at 12:48 +0100, Dimitri Fontaine wrote: Tom Lane t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [DOCS] [HACKERS] Extension versus module
Simon Riggs si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
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-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
