On Sat, 2013-11-30 at 22:55 +0100, Dimitri Fontaine wrote:
> So we need the "default_major_version" capabilities, whatever the
> name we choose. Hence my inclusion of that feature in the Extension
> Template patch.
What we need is a means to install versions for which we don't have full
SQL, but for which there exists some upgrade path.
"default_major_version" is one possible approach to that, but it seems
pretty awkward to me.
> > 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!
The problem with asking for a starting point is that:
(a) It's one more thing to get wrong;
(b) what we really care about is the ending point; and
(c) we have to find a path to the right endpoint, and that path might
surprise the extension author and/or user anyway.
It seems like in any real use case, the author would use a convention
that kept the upgrades/downgrades somewhat sane. A few examples might
be:
* Offer only earliest version and upgrades
* Offer only latest version and downgrades
* Offer full SQL script on major versions and upgrades to the point
releases
I don't see why we are trying to accommodate a case where the author
doesn't offer enough full SQL scripts and offers broken downgrade
scripts; or why that case is different from offering broken upgrade
scripts.
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
