OK, well, what PostGIS needs is the ability for 'ALTER EXTENSION …. UPDATE foo’ to end up with two extensions in the end, ‘foo’ and ‘foo_new’. That’s what’s happening in the 2.x -> 3 upgrade process, as ‘postgis’ becomes ‘postgis’ and ‘postgis_raster’.
Presumably 15 years out from the 1.x -> 2.x we can stop worrying about bundling unpackaged postgis into an extension, and just recommend a hard upgrade dump/restore to the hardy souls still running 1.x. P. > On Feb 26, 2020, at 7:37 AM, Stephen Frost <sfr...@snowman.net> wrote: > > Greetings, > > * Sandro Santilli (s...@kbt.io) wrote: >> On pgsql-hackers we only want to find a future-proof way to "package >> existing objects into an extension". If the syntax >> `CREATE EXTENSION <extname> FROM UNPACKAGED` >> has gone, would it be ok for just: >> `CREATE EXTENSION <extname>` >> to intercept unpackaged objects and package them ? > > No. The reason it was removed is because it's not going to be safe to > do when we have trusted extensions. Perhaps it would be possible to > figure out a way to make it safe, but the reason FROM UNPACKAGED was > created and existed doesn't apply any more. That PostGIS has been using > it for something else entirely is unfortunate, but the way to address > what PostGIS needs is to talk about that, not talk about how this ugly > hack used to work and doesn't any more. > > Thanks, > > Stephen > _______________________________________________ > postgis-devel mailing list > postgis-de...@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/postgis-devel
