On Tue, Jan 10, 2023 at 6:50 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > The script-file-per-upgrade-path aspect solves a problem that you > have, whether you admit it or not; I think you simply aren't realizing > that because you have not had to deal with the consequences of > your proposed feature. Namely that you won't have any control > over what the backend will try to do in terms of upgrade paths. > > As an example, suppose that a database has foo 4.0 installed, and > the DBA decides to try to downgrade to 3.0. With the system as it > stands, if you've provided foo--4.0--3.0.sql then the conversion > will go through, and presumably it will work because you tested that > that script does what it is intended to. If you haven't provided > any such downgrade script, then ALTER EXTENSION UPDATE will say > "Sorry Dave, I'm afraid I can't do that" and no harm is done.
I mean, there is nothing to prevent the extension author from writing a script which ensures that the extension membership after the downgrade is exactly what it should be for version 3.0, regardless of what it was before. SQL is Turing-complete. The thing that confuses me here is why the PostGIS folks are ending up with so many files. We certainly don't have that problem with the extension that are being maintained in contrib, and I guess there is some difference in versioning practice that is making it an issue for them but not for us. I wish I understood what was going on there. But that to one side, there is clearly a problem here, and I think PostgreSQL ought to provide some infrastructure to help solve it, even if the ultimate cause of that problem is that the PostGIS folks managed their extension versions in some less-than-ideal way. I can't shake the feeling that you're just holding your breath here and hoping the problem goes away by itself, and judging by the responses, that doesn't seem like it's going to happen. -- Robert Haas EDB: http://www.enterprisedb.com