[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.

[Regina Obe]

> > 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.

The mention of rtpostgis_uninstall.sql is not clean and I bet will confuse 99% of users.

The rtpostgis_uninstall.sql does not work for a lot of people.
Can you just package this as a function that can be called?

Then in the postgis_extensions_upgrade(), we can just call it if you have unpackaged raster functions in your db and you don't have postgis_raster extension.

This should just be done and not left up to the user to decide, and rolled back if there are raster tables. The reason to not bother the user with this is 
those functions would be from an older PostGIS and dangerous to use with newer PostGIS and since there is no way to upgrade them, they should be chucked if there are not in use.

We can display a notice - "Hey we noticed you don't have raster built with your new version - so we are DROPPING these for you since they aren't used and are dangerous to keep around".

Everyone else, gets the raster extensions automatically packaged and upgraded with a notice they can drop the extension if they don't want it.

That way running:

SELECT postgis_extensions_upgrade();

Will work for everyone.

I'd like to get rid of the mention of uninstall ... .sql from all user facing documentation.

If you are on a DbaaS the mention of rtpostgis_uninstall.sql doesn't work at all.
For newer users of PostGIS, the idea of doing anything via scripts is just foreign and scary.  Assuming they could even find the scripts you are talking about.
Hell I can't find these scripts half the time when I get on a client's server and I've been using postgis for over 15 years, so how can I expect any normal person to.

Installing / uninstalling things these days via scripts in PostgreSQL is deprecated if supported at all. We should be following the "PostgreSQL way" of doing things.

I agree it's useful for our regress tests to install via scripts because of the deficiency of the extension model to expect the scripts to be located in a certain place,
but THAT IS THE ONLY PLACE WHERE THIS IS USEFUL and even there, our regress harness takes care of that, so you never even need to know these things exist
unless you want to fiddle with the regress machinery.

I'd  like to get rid of all the user facing documentation for 3.0+ that talks about upgrading postgis via scripts.
Especially the uninstall scripts, which granted you have improved, but still suck more than doing DROP EXTENSION.


> 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 ?
> 
YES - let's do that.

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

We can test this out, but I suspect it should work since the function itself would be under the postgis extension.
It might not though or vary from cloud platform to cloud platform, but if it doesn't it would be easier for them to make provisions for a function
rather than a filesystem thing where the filesystem is abstracted away.


Thanks,
Regina