[postgis-devel] Pg13 upgrade issues?

rmrodriguez at carto.com rmrodriguez at carto.com
Tue Sep 15 09:39:24 PDT 2020


I've been wondering about this and thought about another solution that I
think is simpler: We could have postgis (core) drop any types and functions
owned by it that now belong to postgis_raster.

The main benefit would be that it will work no matter the PG release or the
source Postgis release. The drawbacks: any dependency on raster (views and
so on) will need to be dropped in this process (only once) and that you
need to install postgis_raster if you use raster (beforehand the functions
were already there).

Any thoughts?

On Friday, September 11, 2020, Sandro Santilli <strk at kbt.io> wrote:

> On Thu, Sep 10, 2020 at 04:23:48PM -0400, Regina Obe wrote:
> > Yap and I think strk created one his strk ingenious idea fixes to fix
> that.  In a pull request https://git.osgeo.org/gitea/
> postgis/postgis/pulls/45
>
> Right, and did not commit because I didn't like that hack very much
> if we have a better way. A possibly better way would be to simply
> have `CREATE EXTENSION postgis*` deal with packaging, without the
> need to append the "FROM UNPACKAGED". Right now if you try you
> get a failure because the extension creation code DOES detect
> presence of unpackaged functions and bails out. Instead of bailing
> out it could package them... But I didn't find the time to try
> such implementation
>
> --strk;
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel



-- 
Raúl Marín Rodríguez
carto.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20200915/77d39b1e/attachment.html>


More information about the postgis-devel mailing list