On Tue, Jan 10, 2023 at 06:50:31PM -0500, Tom Lane wrote:
> With the proposed % feature, if foo--%--3.0.sql exists then the > system will invoke it and expect the end result to be a valid > 3.0 installation, whether or not the script actually has any > ability to do a downgrade. It is sane, for the system to expect the end result to be a valid 3.0 installation if no exception is thrown by the script itself. If we ship foo--%--3.0.sql we must have been taken care of protecting from unsupported downgrades/upgrades (and we did, having the script throw an exception if anything is unexpected). > (I suppose you could add code to look at pg_extension.extversion, We actually added code looking at our own version-extracting function (which existed since before PostgreSQL added support for extensions). Is the function not there ? Raise an exception. Is the function not owned by the extension ? Raise an exception. In other cases -> trust the output of that function to tell what version we're coming from, throw an exception if upgrade to the target version is unsupported. > to add such code is that really better than having a number of > one-liner scripts implementing the same check declaratively?) Yes, it is, because no matter how many one-liner scripts we install (we currently install 87 * 6 such scripts, we always end up missing some of them upon releasing a new bug-fix release in stable branches. > almost certainly you are > going to end with an extension containing some leftover 4.0 > objects, some 3.0 objects, and maybe some objects with properties > that don't exactly match either 3.0 or 4.0. This is already possible, depending on WHO writes those upgrade scripts. This proposal just gives more expressiveness power to those script authors. > So I really think this is a case of "be careful what you ask > for, you might get it". Even if PostGIS is willing to put in > the amount of infrastructure legwork needed to make such a > design bulletproof, I'm quite sure nobody else will manage > to use such a thing successfully. This is why I initially made this something to be explicitly enabled by the .control file, which I can do again if it feels safer for you. > I'd rather spend our > development effort on a feature that has more than one use-case. Use case is any extension willing to support more than a single stable branch while still allowing upgrading from newer-stable-bugfix-release to older-feature-release (ie: 3.2.10 -> 3.4.0 ). Does not seem so uncommon to me, for a big project. Maybe there aren't enough big extension-based projects out there ? --strk; Libre GIS consultant/developer https://strk.kbt.io/services.html
