Re: in-catalog Extension Scripts and Control parameters (templates?) - Mailing list pgsql-hackers

Hi,

Please find attached v2 of the Extension Templates patch, with pg_dump
support and assorted fixes. It's still missing ALTER RENAME and OWNER
facilities, and owner in the dump. There's a design point I want to
address with some input before getting there, though. Hence this email.

Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> We now have those new catalogs:
>
>   - pg_extension_control
>   - pg_extension_template
>   - pg_extension_uptmpl

What I did here in pg_dump is adding a new dumpable object type
DO_EXTENSION_TEMPLATE where in fact we're fetching entries from
pg_extension_control and pg_extension_template and uptmpl.

The thing is that we now have a control entry for any script to play, so
that we can ALTER the control properties of any known target version.
Also, an extension installed from a template keeps a dependency towards
the control entry of that template, so that the dump is done with the
right ordering.

Now, the tricky part that's left over. Say that you have an extension
pair with 3 versions available, and those upgrade paths (edited for
brevity):

    ~# select * from pg_extension_update_paths('pair');
     source | target |     path
    --------+--------+---------------
     1.0    | 1.1    | 1.0--1.1
     1.0    | 1.2    | 1.0--1.1--1.2
     1.1    | 1.2    | 1.1--1.2

    CREATE EXTENSION pair VERSION '1.2';

PostgreSQL didn't know how to do that before, and still does not. That
feature is implemented in another patch of mine for 9.3, quietly waiting
for attention to get back to it, and answering to a gripe initially
expressed by Robert:

  https://commitfest.postgresql.org/action/patch_view?id=968

  Given the ability to install an extension from a default_version then
  apply the update path to what the user asked, we would have been able
  to ship hstore 1.0 and 1.0--1.1 script in 9.2, without having to
  consider dropping the 1.0 version yet.

Now, back to Extension Templates: the pg_dump output from the attached
patch is not smart enough to cope with an extension that has been
upgraded, it will only install the *default* version of it.

There are two ways that I see about addressing that point:

  - implement default_full_version support for CREATE EXTENSION and have
    it working both in the case of file based installation and template
    based installation, then pg_dump work is really straightforward;

    CREATE EXTENSION pair VERSION '1.2'; -- will install 1.0 then update

  - add smarts into pg_dump to understand the shortest path of
    installation and upgrade going from the current default_version to
    the currently installed version of a template based extension so as
    to be able to produce the right order of commands, as e.g.:

    CREATE EXTENSION pair;                -- default is 1.0
    ALTER EXTENSION pair UPDATE TO '1.2'; -- updates to 1.1 then 1.2

As you might have guessed already, if I'm going to implement some smarts
in the system to cope with installation time update paths, I'd rather do
it once in the backend rather than hack it together in pg_dump only for
the template based case.

Should I merge the default_full_version patch into the Extension
Template one, or would we rather first see about commiting the default
one then the template one, or the other way around, or something else I
didn't think about?

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support