On Wed, Mar 8, 2023 at 7:27 AM Sandro Santilli <strk@kbt.io> wrote:
> Now, PostGIS has released a total of 164 versions:
That is a LOT of versions. PostGIS must release really frequently, I guess?
> I guess you may suggest that we do NOT increas the *EXTENSION* version
> number UNLESS something really changes at SQL level, but honestly I
> doubt we EVER released a version with no changes at the SQL level
> (maybe in some occasion for really bad bugs which were only fixed at
> the C level).
Well, that's certainly the design intention here. The point of the
extension version number from the point of PostgreSQL is to provide a
way to cause SQL changes to happen via extension upgrade steps, so if
there's no SQL change required then the version number change has no
purpose from PostgreSQL's point of view. But I do see a problem with
that theory, which is that you might quite reasonably want the
extension version number and your own release version number to match.
That problem doesn't arise for the extensions bundled with core
because every new core release has a new PostgreSQL version number,
which is entirely sufficient to identify the fact that there may have
been C code changes, so we have no motivation to bump the extension
version number unless we need a SQL change. This is true even across
major releases -- an extension in contrib can go for years without an
SQL version bump even though the C code may change repeatedly to
accommodate new major releases.
I wonder if a solution to this problem might be to provide some kind
of a version map file. Let's suppose that the map file is a bunch of
lines of the form X Y Z, where X, Y, and Z are version numbers. The
semantics could be: we (the extension authors) promise that if you
want to upgrade from X to Z, it suffices to run the script that knows
how to upgrade from Y to Z. This would address Tom's concern, because
if you write a master upgrade script, you have to explicitly declare
the versions to which it applies. But it gives you a way to do that
which does not require creating a bazillion empty files. Instead you
can just declare that if you're running the upgrade script from
14.36.279 to 14.36.280, that also suffices for an upgrade from
14.36.278 or 14.36.277 or 14.36.276 or ....
--
Robert Haas
EDB: http://www.enterprisedb.com
