postgis_extensions_upgrade you package any unpackaged postgis included extensions

[robe]

Per strk's suggestion,

If postgis_extensions_upgrade finds any extensions included as part of PostGIS unpackaged it should package them.

Right now it only does it for postgis_raster

So that would be

postgis
postgis_topology
postgis_sfcgal
postgis_tiger_geocoder

I'm leaving address_standardizer out since it was never allowed to install without extensions and doesn't depend on postgis.

[strk]

How do we tell if "tiger_geocoder" exists as unpackaged, in a database ?

[strk]

I've a working version, running final tests

[strk]

In 16880:

Have postgis_extensions_upgrade() package unpackaged extensions

See #4196

NOTE: it doesn't re-package tiger geocoder because I would not

know how to tell if the support for it is installed and
it does't re-package topology due to bug #2503

[strk]

The status of extension of postgis is reported by postgis_full_version, but when the extension was just re-packaged by postgis_extensions_upgrade such status changed within the same transaction, so is not visible by the function. May I suggest we _stop_ reporting full version from within the function ?

[strk]

Another reason why running postgis_full_version() by the end of postgis_extensions_upgrade() fails is that re-pointing scripts to a newer SO file it will take a new LOAD for the new lib_versions() to show up, often resulting in a misleading WARNING about procs needing upgrade... This one may possibly be fixed by issuing an explicit LOAD, but the other issue ([EXTENSION] label being wrong) isn't easy to fix. I would just print a generic text or even nothing

[strk]

Regina I'm closing this ticket because is completed as far as I can tell, but I still think postgis_extensions_upgrade should _not_ return postgis_full_version, because it is giving the _wrong_ information by doing it. Would be worth another ticket but I'm also going to sleep right now :)