Jeff Davis <pg...@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 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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers