Re: Extension Templates S03E11 - Mailing list pgsql-hackers

Jeff Davis <pgsql@j-davis.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
thelatter,   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
and1.1. 
   Note that it's problematic given the current implementation of   pg_upgrade, where when migrating from 9.1 to 9.2
(IIRCthat's when   hstore got to 1.1) you can result in either still having hstore 1.0   in your database if you used
pg_upgradeor 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
cannotcontinue using   hstore 1.0. 
   So the goal is to simplify extension authors management of sql   install and upgrade scripts while giving more
optionsto 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
theupgrade 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
version1.1. 
   So we need the "default_major_version" capabilities, whatever the   name we choose. Hence my inclusion of that
featurein 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