Re: ALTER EXTENSION UPGRADE, v3

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> In principle we are leaving it to the extension author to choose that.

Most extensions already have a version number. ip4r is 1.05, prefix is
1.1.0, dbi-link is 2.0.0, temporal is 20091213, tablelog is 0.4.4, etc.
All those extensions will need a newer 'extension' release to ship with
the control file, at least. So those are some of the old version
numbers that we will find.

> However, we're going to have to make a choice for the contrib modules,
> and I'll bet lunch that most people will follow whatever precedent we
> set with those. I was thinking about using either "old" or "unpackaged".
> Thoughts?

Will we have to provide different upgrade scripts for different past
major versions of PostgreSQL? If so, I would say "9.0" or "8.4" would
be better names. hstore at least is an example that would need this
treatment I guess.

Now we could trick and prepend a "0." so that it's easy to break the old
version naming system and get to use a proper per-extension numbering
here. That would mean that core provided extension could have a
different release cycle than the core product. Do we want that?

Thinking about that, maybe what we want to do with contrib is separate
that in several directories, like e.g. "examples", "extensions", "tools"
and such. Tools would fit contribs that do not ship with SQL level
support, like pg_archivecleanup or pg_standby and some others. Each
time contrib quality is talked about we're explained that most of them
are examples only, not production ready quality code, hence my proposal.

> It can be specified by a "directory" parameter in the control file,
> and defaults to the same place the control file is. Right now, that's
> $PREFIX/share/contrib/. One other thing that ought to be discussed is
> whether to stick with that choice or change it. Given that some people
> have great antipathy to the word "contrib", I suspect there will be
> argument to change it --- but to do so, I think we'd have to change the
> default MODULEDIR in PGXS, and I'm not sure that's a good idea.

I don't readily grasp the consequences of that.

>>> Version strings will have no hard-wired semantics except equality; we
>>> don't need a sorting rule. We must however forbid "-" in version
>>> strings, to avoid ambiguity as to whether a file name represents an
>>> install or upgrade script.
>
>> Yeah. Might be worth considering using some other less common character as the delimiter. Maybe + or ^? not a big deal, though. I guess / should also be forbidden, eh?
>
> I could go with + ... anyone know if that is problematic in filenames on
> Windows or elsewhere?

It would be good to avoid regexp and globing pattern characters, I would
say.

There's the coma, as in "foo,1.0,1.1.sql", so ugly that it's unused :) I
wonder if : would be good? "foo:1.0:1.1.sql". A very quick test seems
to show that macosx is ok with that scheme.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support