Re: ALTER EXTENSION UPGRADE, v3

"David E. Wheeler" <david@kineticode.com> writes:
> Sounds good. One nit: can't we call the line in the control file "version" rather than "default_version"? I've been thinking of the control file as describing a release of an extension, which of course has a version, not a default version.

No --- in the current vision, a control file may describe a whole
collection of versions of the same extension, and the parameter in
question is selecting the default or preferred version to install.
I'm not wedded to "default_version", but I think just plain "version"
is a misnomer.

> Oh, so what should oldv be to indicate creating from a legacy extension?

In principle we are leaving it to the extension author to choose that.
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?

> How do you determine the "script directory"?

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.

>> (NOTE: maybe in the CREATE ... FROM case, it would be
>> a better idea to not do that search, but insist on finding exactly
>> extname-oldv-v.sql?  That would provide at least a little bit of extra
>> protection against wrong FROM choice.  Not sure how much it helps
>> though.)

> Meh. Just goes to creating more work for the extension maintainer, who would then have to consider whether or not to make a bunch of omnibus upgrade scripts for any given release, just in case some user specified a FROM clause. Not thrilled with that. Seems to me either there's a chain or there isn't.

Fair enough.

>> 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?

			regards, tom lane