Re: ALTER EXTENSION UPGRADE, v3

Tom Lane <tgl@sss.pgh.pa.us> writes:
> 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]

Agreed.

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

Check.

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

Well I don't think it's the same default, but I'm in the minority, so
you got your votes here already.  Just for the record and summary.

> 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.)

Chaining in all cases is better.  Less documentation, less code, less
burden on authors.  Better :)

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

That allows to get prepared for version aliases if we ever get there
too. Good.

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

Check.  We could use : as the version separator too.

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

I would think that if we have the extname-v.control facility, which I
think we must have, we should check for this file at each steps of the
chain, and override each time.  Encodings are not what I'm worried about
here, 'required' is.

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