[postgis-devel] PSC Vote: Drop the minor in the postgis lib files

[Sebastiaan Couwenberg]

On 9/27/18 5:30 PM, Sandro Santilli wrote:
> On Thu, Sep 27, 2018 at 05:14:50PM +0200, Sebastiaan Couwenberg wrote:
> 
>> When users upgrade from, for example, jessie to stretch, they need to
>> upgrade their database cluser from postgresql-9.4 with
>> postgresql-9.4-postgis-2.1 (which provides postgis-2.1.so) to
>> postgresql-9.6 with postgresql-9.6-postgis-2.3 (which provides
>> postgis-2.3.so).
> 
> When you say "they need to upgrade" you mean the package manager
> forces that upgrade ? Because you mention there's a _single_ version
> of PostgreSQL supported, so I'm wondering if users can have two ONLY
> during an upgrade.

The need to upgrade, because the security support for the old stable
distribution last only one year after the release of the new stable
distribution. The same goes for important bugfixes in stable updates.

If you want to keep you system using supported packages, you need to
upgrade.

Because the PostgreSQL version is part of the package name, both
versions are installed in parallel to enable the user to use pg_upgrade
to migrate their cluster to the new version. Except that pg_upgrade does
not work with databases that use the postgis extension.

>> pg_upgrade fails because the new cluster does not have postgis-2.1. And
>> users are forced to recreate their database from scatch if they don't
>> want to use the symlink hacks which require modifying paths managed by
>> the packaging system. Those symlinks will not be remove with their next
>> distribution upgrade because they are not part of a package that is
>> being removed leaving cruft on the users filesystem they have to
>> manually cleanup.
> 
> They'd need symlinks only until they properly upgrade all databases.
> Again, is this done automatically by Debian packagers ?
> Otherwise we could provide a script ourselves to do it.
> The script would:
> 
>    1. Create symlinks if needed
>    2. Run pg_upgrade
>    3. Update postgis in all databases [*]
>    4. Drop the symlinks

A wrapper around pg_upgrade is an option to support postgis databases,
but not having to do so in the first place is preferable. Why does
postgis not play nice with postgresql database upgrades like other
extensions do? That's a big pain point for users.

> What concerns me is the handling of failures in step 3, both
> in the manual case and (worst?) in the automatic case.

Kind Regards,

Bas