Re: Extension Templates S03E11 - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Extension Templates S03E11
Date
Msg-id 1386146347.19125.240.camel@jdavis
Whole thread Raw
In response to Re: Extension Templates S03E11  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Extension Templates S03E11
List pgsql-hackers
On Tue, 2013-12-03 at 10:23 -0500, Robert Haas wrote:
> In more normal cases, however, the system can (and probably should)
> figure out what was intended by choosing the *shortest* path to get to
> the intended version.  For example, if someone ships 1.0, 1.0--1.1,
> 1.1, and 1.1--1.2, the system should choose to run 1.1 and then
> 1.1--1.2, not 1.0 and then 1.0--1.1 and then 1.1--1.2.  But that can
> be automatic: only if there are two paths of equal length (as in the
> example in the previous paragraph) do we need help from the user to
> figure out what to do.

Why do we need help from the user? Just pick a path.

For an extension update, I understand why someone wouldn't want to
accidentally downgrade 5 versions (dropping all of their dependent
objects) before updating to the latest. But this doesn't apply to
creation.

And it just seems really awkward to document, and it's a constant
maintenance burden on extension authors to specify their upgrade paths
every time they release a new version.

> Putting all that together, I'm inclined to suggest that what we really
> need is a LIST of version numbers, rather than just one.  If there one
> path to the version we're installing is shorter than any other, we
> choose that, period.  If there are multiple paths of equal length, we
> 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.

That seems like extreme overkill, and still doesn't give users full
control over upgrade paths.

Regards,Jeff Davis






pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: logical changeset generation v6.7
Next
From: Heikki Linnakangas
Date:
Subject: Re: Why we are going to have to go DirectIO