Re: Review: extension template

> 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 <hannu(at)krosing(dot)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