[postgis-devel] [postgis-tickets] r16847 - Revise postgis_extensions_upgrade to repackage raster if it finds it unpackaged. Revise unpackage notice to say to give instruction to call the postgis_extensions_upgrade function and repackage.

[Sandro Santilli]

On Fri, Sep 28, 2018 at 02:43:05PM -0400, Regina Obe wrote:
> > On Thu, Sep 27, 2018 at 02:50:36AM +0000, Regina Obe wrote:

> > 1. It makes `postgis_extensions_upgrade` function do more than it was
> >    meant to do (automatically package unpackaged code) and do it partially
> >    (only does for raster, not for other postgis extensions, and it is not
> >    documented to do it).
> 
> It is meant to upgrade extensions, repackaging raster functions as part of postgis_raster 
> I think falls in the extension upgrade category and it doesn't need
> to be done for other extensions because other extensions were always
> self-standing.

Every component of PostGIS can currently be installed either as an
extension (packaged) or as standalone scripts (extension). This is
not limited to raster.

Packaging a scripts-based install is already supported by core
PostgreSQL syntax: CREATE EXTENSION xxxx FROM unpackaged

> If you had installed postgis with extension support presumably you'd
> want raster to be repackaged as an extension.

I agree, and you can do so by running:

  CREATE EXTENSION postgis_raster FROM unpackaged;

> Note it only does this if it notices you have postgis installed as an
> extension and have unpackaged raster functions.

This is not necessarely an indication that you want to re-package raster.
As there's an explicit command to run for repackaging raster we can let
the user decide whether or not she wants to do that. I don't like forcing
packaging when someone just asks to "upgrade postgis extensions".

> The script checks before running to see if you had postgis packaged
> and you have raster functions unpackaged.  Presumably if you started
> off with postgis unpackaged
> And decided to have it packaged, you would want postgis_raster to be
> packaged as well.

Possibly yes. But the fact you're running "postgis_extension_upgrade"
doesn't give any indication of you having started off with postgis
unpackaged and decided to have it packaged, because then all you
were doing was:

  CREATE EXTENSION postgis FROM unpackaged;

> So are you thinking of those people who - built with raster support
> in say 2.5.0, then built with PostGIS 3.0.0 support without raster?
> I suspect there will be very few of those folks.  

One of the good things about free software is that it cares about
the few, not needing to deal with scale economy.

> A solution to that problem might be to have a 
> 
> CREATE EXTENSION postgis_raster FROM unpackaged;
> 
> For people who don't have raster installed but currently have raster functions, which doesn't try to do a raster upgrade as well.
> In that case, you can even just drop the raster functions for them, because they won't be able to use them anyway. :)

Right, thus the uninstall via script instructions.
Original instructions were saying:

 If you want to package raster, do:

     CREATE EXTENSION postgis_raster FROM unpackaged;

 If you want to drop raster, load:

     rtpostgis_uninstall.sql

The above is clean and always works both directions.
If what you don't like is the need to load files from system
in order to uninstall we could provide an uninstall function,
do you think it would help ?

> This would also have the benefit of working for people who have cloud
> platforms, but the cloud provider decided in 3.0 to no longer support
> raster.
> In such cases, people won't be able to use the uninstall_rtpostgis.sql
> script anyway since they don't have access to the file system and dbaas
> tend to have pseudo super user rights that doesn't allow running scripts
> that drop C functions.

The uninstall script doesn't need to be on the cloud platform, it is
enough for it to be on the client side.

As per the pseudo-super-user-rights, would an uninstall function help ?

--strk;