Re: Extension Templates S03E11

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> I think that Stephen was just talking about the naming. I would have
> expected the names to be something like "xtmpl" (which is the shortest
> abbreviation that came to my mind) rather than "tpl", for instance. Use
> of "template" is a bit ambiguous.

To be honest I'm not following along with the complaint. What object
would you liked to be named xtmpl rather than what it is called now?

If you're refering to the catalog column names such as tplname and
tplowner and the like, the tradition AFAICS is to find a trigram prefix
for those entries… and that's what I did.

> However, I find the "full version" quite awkward still. I don't think
> it's purely a documentation issue -- the "default full version" concept
> itself is a bit awkward.

Yes. I coulnd't find a better name, and I would quite like that we do.

There are two ideas behind that feature:

- When we released hstore 1.1 we had a choice of either providing
still hstore--1.0.sql and hstore--1.1.sql or only the latter,
deprecating the 1.0 version for the next release.

The default_major_version feature allows to only ship hstore-1.0.sql
and still offer full support for hstore 1.0 and 1.1.

Note that it's problematic given the current implementation of
pg_upgrade, where when migrating from 9.1 to 9.2 (IIRC that's when
hstore got to 1.1) you can result in either still having hstore 1.0
in your database if you used pg_upgrade or have hstore 1.1 already
if you used pg_dump and pg_restore.

Note also that if you install 9.2 then by a technically constrained
choice of policy in the project, then you cannot continue using
hstore 1.0.

So the goal is to simplify extension authors management of sql
install and upgrade scripts while giving more options to the users
of extension wrt the version they want to be using.

- With Extension Templates, the extension author can be providing
scripts foo--1.0.sql and foo--1.0--1.1.sql and run the upgrade with

ALTER EXTENSION foo UPDATE TO '1.1';

Now what happens at pg_restore time? We only have the 1.0 and
1.0--1.1 scripts, yet we want to be installing foo version 1.1.

So we need the "default_major_version" capabilities, whatever the
name we choose. Hence my inclusion of that feature in the Extension
Template patch.

> If I understand correctly, it goes something like this:
>
> When a user does:
> CREATE EXTENSION foo VERSION '3.0';
>
> and there are templates for 1.0, 2.0, and 2.1, and upgrades from
> 1.0->2.0, 2.0->2.1, and 2.1->3.0, then there are three possible actions
> that might be taken:
>
> 1. Install 1.0 and run three upgrades
> 2. Install 2.0 and run two upgrade
> 3. Install 2.1 and run one upgrade

With PostgreSQL versions 9.1, 9.2 and 9.3, given the scripts you're
listing, the command you propose will just fail. Full stop. ERROR.

> The second one (in an "else" branch) shouldn't happen, assuming
> default_full_version points at a proper full version, right?

Will review, thanks.

> It seems like it's for pg_dump, so it can avoid outputting the extension
> templates and just say "VERSION 'x.y'" without worrying about which
> version it needs to start from.

Exactly. We need pg_dump to be smart enough for handling the case as
soon as we have Extension Templates, and we already have said smarts in
the backend code. They were just not applied at CREATE EXTENSION time
before this patch.

> That seems like a legitimate purpose, but I think we can come up with
> something that's a little easier on users and easier to document (and
> name). Perhaps just find the shortest upgrade path to the version
> requested (using some arbitrary but deterministic tiebreaker)?

The danger is that the shorter path could well include a downgrade, and
nobody tests for downgrading paths IME. So I keep thinking we should ask
the extension author to give us a starting point. Now, if you have a
better name for it than “default_full_version”, I'm all ears!

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