Re: ALTER EXTENSION UPGRADE, v3

OK, let me see if I can summarize what I think we've agreed to:

CREATE syntax is extended to
CREATE EXTENSION extname [WITH] [SCHEMA s] [VERSION v] [FROM oldv]

If VERSION is not specified, v is taken from default_version in the
control file, or fail if that's not given either.  We create the
pg_extension entry and then run the script extname-v.sql, or
extname-oldv-v.sql if FROM is present.

ALTER syntax is extended with
ALTER EXTENSION extname UPDATE [TO v]

Again, if v is not specified, it is taken from default_version in the
control file, or fail if that's not given either.  Here we take oldv
from the current pg_extension.extversion field, and then run the script
extname-oldv-v.sql.

We will add logic to find a chain of update scripts leading from oldv to
v, in case that exact combination is not available in the extension's
script directory.  (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.)

Version identifiers will be ColId_or_Sconst in the grammar, ie, you can
omit quotes if they're valid SQL identifiers.  I'm not sure this helps
with typical choices of version strings, but we might as well allow it.

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.  (Note: "-" in extension names poses a
hazard as well; not within a single extension, but for example
foo-bar's install scripts could be confused with foo's upgrade
scripts.  However, I think we need not forbid "-" in extension names
since this risk can be avoided by giving foo-bar its own script
directory.)  It also seems to me to be a good idea to forbid ".." and
directory separators in both types of names, because otherwise CREATE
EXTENSION could be used to probe the file system.  That's not really an
issue right now, with use of the command being restricted to superusers
anyway, but it's inevitable that we'll want to relax that restriction.

We will also add code to allow per-version control files
extname-v.control in the script directory.  After determining the
version we plan to install or update to, we read the per-version control
file if any, and let it override parameters from the primary control
file.  (This implies for example that a per-version control file's
encoding setting would control all update scripts read while trying to
get to that version.  I'm not sure how useful that is --- given the
chaining behavior, really you're going to have to use the same encoding
throughout the extension's update files.  Maybe better to disallow
encoding in per-version control files?)

Comments?
        regards, tom lane