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
thinkingof 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
makea bunch of omnibus upgrade scripts for any given release, just in case some user specified a FROM clause. Not
thrilledwith 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