"David E. Wheeler" <da...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
