[postgis-devel] Upgrade paths (again)
Sandro Santilli
strk at kbt.io
Wed Sep 14 07:03:21 PDT 2022
On Wed, Sep 14, 2022 at 08:31:11AM -0400, Greg Troxel wrote:
> Sandro Santilli <strk at kbt.io> writes:
> > On Sun, Aug 14, 2022 at 06:50:13AM -0400, Greg Troxel wrote:
> >> Sandro Santilli <strk at kbt.io> writes:
> >
> > There is no "right bits" as those depend on the status of the machine.
> > What's "right" depends on what versions users need to upgrade from,
> > thus the script (which can only partially determine that, in its
> > current state).
>
> I see. Well, my view is that in packaging we try to push as many things
> into "build", and do as little as possible/reasonable at install time.
>
> And, at package installation time, it is quite possible that pgsql is
> not running, and the package manager probably doesn't have database
> privs.
I've changed the 'upgrade-paths' code so to not require PostgreSQL at
all but keep the current model of installing explictly stated upgrade
paths from old supported versions. The new aim is simply avoiding the
need to run updates on system catalogs.
The new packaging problem with this model is that the SAME file would
be included in multiple packaged postgis versions, namely upgrade
paths in the form:
postgis--3.0.0--ANY.sql
The above file would be installed by all future postgis versions.
This is the reason why I'm thinking we should not install them
(nor include in the binary packages) at all but delegating that
operation to the system administrator. But I agree it would not
be easy for the system aministrator (or DBA?) to tell what
version of postgis the available databases might be using, which
basically means iterating over all databases and gathering this
info:
select extversion from pg_extension where extname = 'postgis';
--strk;
Libre GIS consultant/developer
https://strk.kbt.io/services.html
More information about the postgis-devel
mailing list