Re: ALTER EXTENSION UPGRADE, v3

Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> I think we should embed the version number in the script file name,

> What I don't like in that is that this restrict what the version strings
> can look like.  In debian for example it's pretty common to use the ~
> separator, because 1.0~alpha1 < 1.0~beta < 1.0 with their sorting rules.
> And this trick won't work on windows filenames, AFAIK.  That's one
> reason why I've wanted to stay away from having the version number
> strings encoded into the filename in the first place.

Well, yeah, but if you accept the principle that there should be a
separate script file for each version and update combination, you're
pretty much going to have to embed the version strings into the
filenames to keep your sanity.

My feeling about this is that we should recommend that version
identifiers be limited to ASCII letters, digits, dots, and underscore,
but assume that extension authors are adults and can grasp the risks
of using other characters.  We should not be in the business of trying
to force authors to write portable code whether they want to or not.

> But if you get to sorting rules of version strings, you have to define
> them properly and impose them to users.

I think we've now converged on the agreement that we don't need to use
anything but equality checks.  So it doesn't matter how the author
thinks the strings sort --- the upgrade scripts he provides define what
can follow what, and that's all we need to know.

> That way a SQL query can check if there's a new version available on
> your system.  That's useful in some places to use as a monitoring alert
> coupled with nagios.  The sysadmin team does the apt-get install part of
> the job and then the DBA team is paged to go upgrade the extensions in
> the databases, or shut the alarm somehow.

Well, you could look to see if there is a script that can update your
current version to something else.  The existing pg_available_extensions
view needs to be rethought a bit, probably, but I'm not sure how.

>> So, concrete proposal is to enforce the "extension-version.sql" and
>> "extension-oldversion-newversion.sql" naming rules for scripts, which
>> means getting rid of the script name parameter in control files.

> Well, just for the record, we could extend the script property to be a
> key value thing that pairs a version string with an upgrade script
> name.

Yeah, but that doesn't get you away from having to name the script files
somehow, and it isn't going to be pleasant for anybody to use a naming
convention that isn't basically embedding the version numbers.  We could
argue about details like whether dash is the best separator, but that's
pretty far down the list of important things.

>> "version" parameter should be renamed to something like "current_version"
>> or "default_version".  We also have to be wary of whether any other

> I can already hear people wanting version aliases instead.  We could
> support e.g. 4 or 5 aliases like 'stable', 'support', 'alpha', 'beta'
> and maybe 'experimental'.  Then rather than defining "current_version"
> authors would define any set of those keywords here, and CREATE
> EXTENSION and ALTER EXTENSION would by default only care for
> resp. 'stable' and 'support'.

Hmm.  That might be worth doing, but let's leave it for later when we
find out how much demand there really is.  It does strike me that what
we ought to call the default-version parameter is just "default", since
that would fit in reasonably well with such an extension later.
        regards, tom lane