Laurenz Albe <laurenz.albe@cybertec.at> writes:
> I don't think this idea is fundamentally wrong, but I have two worries:
> 1. It would be a good idea good to make sure that there is not both
> "extension--%--2.0.sql" and "extension--1.0--2.0.sql" present.
> Otherwise the behavior might be indeterministic.
The existing logic to find multi-step upgrade paths is going to make
this a very pressing problem. For example, if you provide both
extension--%--2.0.sql and extension--%--2.1.sql, it's not at all
clear whether the code would try to use both of those or just one
to get from 1.x to 2.1.
> 2. What if you have a "postgis--%--3.3.sql", and somebody tries to upgrade
> their PostGIS 1.1 installation with it? Would that work?
> Having a lower bound for a matching version might be a good idea,
> although I have no idea how to do that.
The lack of upper bound is a problem too: what stops the system from
trying to use this to get from (say) 4.2 to 3.3, and if it does try that,
will the script produce a sane result? (Seems unlikely, as it couldn't
know what 4.x objects it ought to alter or remove.) But it's going to be
very hard to provide bounds, because we intentionally designed the
extension system to not have an explicit concept of some versions being
less than others.
I'm frankly skeptical that this is a good idea at all. It seems
to have come out of someone's willful refusal to use the system as
designed, ie as a series of small upgrade scripts that each do just
one step. I don't feel an urgent need to cater to the
one-monster-script-that-handles-all-cases approach, because no one
has offered any evidence that that's really a better way. How would
you even write the conditional logic needed ... plpgsql DO blocks?
Testing what? IIRC we don't expose any explicit knowledge of the
old extension version number to the script.
regards, tom lane
