> On 07/08/2013 09:26 AM, Heikki Linnakangas wrote: >> I'm just now dabbling back to this thread after skipping a lot of >> discussion, and I'm disappointed to see that this still seems to be >> running in circles on the same basic question: What exactly is the >> patch trying to accomplish.
Bypassing the file system entirely in order to install an extension. As soon as I figure out how to, including C-coded extensions. >> I think the reason is that extensions provide some handy packaging of >> the functions etc, so that you can just do "DROP EXTENSION foo" to get >> rid of all of them. Also, pg_extension table keeps track of the >> currently installed version. Perhaps we need to step back and invent >> another concept that is totally separate from extensions, to provide The main feature of the extensions system is its ability to have a clean pg_restore process even when you use some extensions. That has been the only goal of the whole feature development. Let me stress that the most important value in that behavior is to be able to pg_restore using a newer version of the extension, the one that works with the target major version. When upgrading from 9.2 to 9.3 if you depend on keywords that now are reserved you need to install the newer version of the extension at pg_restore time. The main features I'm interested into beside a clean pg_restore are UPDATE scripts for extensions and dependency management, even if that still needs improvements. Those improvements will be relevant for both ways to make extensions available for your system. >> those features. Let's call them "modules". A module is like an >> extension, in that all the objects in the module can be dropped with a >> simple "DROP MODULE foo" command. To create a module, you run "CREATE >> MODULE foo AS <SQL script to create the objects in the module>". Not again the naming. A module is already documented as a shared object library (.so, .dll or .dylib) that PostgreSQL will LOAD for you. A patch has already been proposed to track which module is loaded in a session and offer that in a new system's view, pg_module. We can not use the name "module" for anything else, IMNSHO. >> just with the name. 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. The main goal here is not to have the extension live inside the database but rather to be able to bypass using the server's filesystem in order to be able to CREATE EXTENSION foo; and then to still have pg_restore do the right thing on its own. If you want to scratch the new catalogs part, then just say that it's expected to be really complex to pg_restore a database using extensions, back to exactly how it was before 9.1: create the new database, create the extensions your dump depends on in that new database, now pg_restore your backup manually filtering away the extensions' objects or ignoring the errors when pg_restore tries to duplicate functions you already installed in the previous step. No fun. Hannu Krosing <ha...@krosing.net> writes: > Either MODULE or PACKAGE would be good name candidates. The name "package" is even worse than the "module" one because lots of people think they know exactly what is a package for having been using a closed source product that you might have heard of: they are trying to cope with our ability to implement new features on a yearly basis while not breaking anything we already have. > Still, getting this functionality in seems more important than exact > naming, though naming them "right" would be nice. Of course we want to do it right™. 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
