On Wed, 2013-11-27 at 18:34 +0100, Dimitri Fontaine wrote:
> Stephen Frost <sfr...@snowman.net> writes:
> > We already have other 'template' objects in the system and I'm not
> > excited about the confusion. This also applies to 'CreateTemplate',
> > 'CreateTemplateTupleDesc', right down to 'template.h' and 'template.c'.
>
...
> We could of course have a 50 lines templates.c file that calls into an
> extension_template.c file for the meat of the implementation if that's
> prefered by the project.
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.
> I merged your patch in, rebased against master, fixed some more typos I
> found, and filled in the gaps you found in the docs. Version 17 of the
> patch is attached to that email, passes `make check`.
>
> ENOTIME for building docs, will do tomorrow, I though you might
> appreciate an update meanwhile (and with some luck docs still build
> fine).
Yes, they build fine.
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.
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
There are two ways to disambiguate:
1. Specify the initial version using "FROM 2.0" in CREATE EXTENSION
command (though the documentation seems to say that the FROM clause is
only useful for unpackaged, for some reason)
2. If not specified there, it falls through to DEFAULT FULL VERSION
for the extension template
But that's a little strange. Many extensions are likely to have all
relevant versions available in full, and DEFAULT FULL won't kick in.
Those that do make use of upgrade-only paths are likely to have a few
full versions and a few upgrade scripts based off each. If you pick a
default full version of 2.0, then it won't be useful for installing
version 1.0, nor version 23.7. In each of those cases, you'll want to
specify the FROM clause in CREATE EXTENSION.
I suppose the idea is to avoid the need for specifying "FROM" in the
common case where you want to install the latest version. But it seems
like you could just as well keep a full copy of the extension's latest
version, and just prune them out when they become old.
Unless I'm missing something, I'd be inclined to just get rid of the
concept of DEFAULT FULL VERSION just to keep the documentation simpler
without losing any real functionality.
In passing, I'll also make a quick complaint about the code:
/*
* If we have a full script for the target version (or a create
template),
* we don't need to care about unpackaged or default_major_version, nor
* about upgrade sequences.
*/
...
* If the user did
* ask for a target version that happens to be the same as the
* default_full_version, just install that one directly.
The second one (in an "else" branch) shouldn't happen, assuming
default_full_version points at a proper full version, right?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
