On Wed, Mar 8, 2023 at 7:27 AM Sandro Santilli <s...@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
