On Wed, Feb 26, 2020 at 12:17:37AM -0800, Andres Freund wrote: > Hi, > > On 2020-02-26 09:11:21 +0100, Sandro Santilli wrote: > > PostGIS uses unpackaged-to-XXX pretty heavily, and has it under > > automated testing (which broke since "FROM unpackaged" support was > > removed, see 14514.1581638...@sss.pgh.pa.us) > > > > We'd be ok with requiring SUPERUSER for doing that, since that's > > what is currently required so nothing would change for us. > > > > Instead, dropping UPGRADE..FROM completely puts us in trouble of > > having to find another way to "package" postgis objects. > > Coul you explain what postgis is trying to achieve with FROM unpackaged?
We're turning a non-extension based install into an extension-based one. Common need for those who came to PostGIS way before EXTENSION was even invented and for those who remained there for the bigger flexibility (for example to avoid the raster component, which was unavoidable with EXTENSION mechanism until PostGIS 3.0). For the upgrades to 3.0.0 when coming from a previous version we're using that `FROM unpackaged` SYNTAX for re-packaging the raster component for those who still want it (raster objects are unpackaged from 'postgis' extension on EXTENSION UPDATE because there was no other way to move them from an extension to another). I guess it would be ok for us to do the packaging directly from the scripts that would run on `CREATE EXTENSION postgis`, but would that mean we'd take the security risk you're trying to avoid by dropping the `FROM unpackaged` syntax ? --strk;
