Re: Extension Templates S03E11 - Mailing list pgsql-hackers

On Tue, Dec 3, 2013 at 11:44 AM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
>> We should also consider the possibility of a user trying to
>> deliberately install and older release.  For example, if the user has
>> 1.0, 1.0--1.1, 1.1, 1.1--1.2, and 1.2--1.0 (a downgrade script) with
>> default_full_version = 1.2, an attempt to install 1.0 should run just
>> the 1.0 script, NOT 1.2 and then 1.2--1.0.
>
> In what I did, if you want version 1.0 and we have a script --1.0.sql
> around, then we just use that script, never kicking the path chooser.

Oh, right.  Duh.  Sorry, bad example.  I do think we want to avoid
using a downgrade script as part of an install though - and to install
from the newest possible full version (I kind of like the term "base"
version) whenever possible.

>> break the tie by choosing which version number appears first in the
>> aforementioned list.  If that still doesn't break the tie, either
>> because none of the starting points are mentioned in that list or
>> because there are multiple equal-length paths starting in the same
>> place, we give up and emit an error.
>
> Jeff also did mention about tiebreakers without entering into any level
> of details.
>
> We won't be able to just use default_version as the tiebreaker list
> here, because of the following example:
>
>   default_version = 1.2, 1.0
>
>   create extension foo version '1.1';
>
> With such a setup it would prefer 1.2--1.1 to 1.0--1.1, which doesn't
> look like what we want. Instead, we want
>
>   default_version = 1.2
>   create_from_version_candidates = 1.0
>
>   create extension foo version '1.1';
>
> Then the tie breaker is the 1.0 in "create_from_version_candidates" so
> we would run foo--1.0.sql and then foo--1.0--1.1.sql.

I guess one way to skin this cat would be to just let the user provide
an ordering for the versions i.e.

version_ordering = 1.0 1.1 1.2

When the user asks for version X, we reject any paths that pass
through a newer version (so that we never downgrade), and start with
the path that begins as close to the target version as possible.  For
scenarios were people might be installing either an older or newer
version, that might be easier to understand than a base-version
preference list.

> Baring objections, I'm going to prepare a new branch to support
> developping that behavior against only file based extensions, and submit
> a spin-off patch to the current CF entry.

Not totally sure we're all on the same page yet, but that's not
necessarily meant to dissuade you.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company