[postgis-devel] Separate make target to install extension upgrade scripts ?

[Paul Ramsey]

Most of this mess stems from the Original Sin of having a versioned .so file, which in turn necessitates a Huge Upgrade, as all the existing functions need to be re-pointed to the new versioned so. If we had immediately decided "there will be only one version of postgis per pgsql cluster" we could have moved to incremental upgrade scripts and generally had a much more pleasant life. As it stands now, it feels like the hole we have been digging is 100 feet deep and I cannot even see the sky anymore. 

P

> On Jan 26, 2023, at 10:27 AM, Sandro Santilli <strk at kbt.io> wrote:
> 
> On Thu, Jan 26, 2023 at 11:56:21AM -0500, Greg Troxel wrote:
>> Sandro Santilli <strk at kbt.io> writes:
>>> 
>>> As a package, if you can tell WHICH older version is going to be
>>> removed, you could just run:
>>> 
>>>  postgis install-extension-upgrades $OLDVERSION
>>> 
>>> after having installed the new version.
>> 
>> Interesting, but for pkgsrc we really can't tell what the old version
>> was.
> 
> And we can't tell from PostGIS build scripts either,
> we just maintain this ever-growing list of old releases
> but it's always partial, as we know.
> 
> The only time you need those scripts is when upgrading
> PostGIS from a version to another, is it really the case
> that package management tools have no idea about the old
> version of packages that get upgraded ? Could there at least
> be a script run AFTER-REMOVAL ? Such script could update a
> log of postgis versions ever installed on the system, then
> upon installing a new postgis, upgrade paths for ALL those
> ever-installed versions could be isntalled.
> 
> --strk; 
> 
>  Libre GIS consultant/developer
>  https://strk.kbt.io/services.html
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel