Re: [postgis-devel] About EXTENSION from UNPACKAGED on PostgreSQL 13 - Mailing list pgsql-hackers

From Sandro Santilli
Subject Re: [postgis-devel] About EXTENSION from UNPACKAGED on PostgreSQL 13
Date
Msg-id 20200227083224.GA6597@liz
Whole thread Raw
In response to Re: [postgis-devel] About EXTENSION from UNPACKAGED on PostgreSQL 13  (Chapman Flack <chap@anastigmatix.net>)
Responses Re: [postgis-devel] About EXTENSION from UNPACKAGED on PostgreSQL 13
List pgsql-hackers
On Wed, Feb 26, 2020 at 11:18:43AM -0500, Chapman Flack wrote:
> On 2/26/20 10:52 AM, Sandro Santilli wrote:
> 
> > This part is not clear to me. You're _assuming_ that the unpackaged--xxx
> > will not make checks, so you _drop_ support for it ? Can't the normal
> > extension script also be unsafe for some reason ? Or can't the
> > unpackaged-xxx script be made safe by the publishers ? Or, as a last
> > resort.. can't you just mark postgis as UNSAFE and still require
> > superuser, which would give us the same experience as before ?
> 
> I am wondering: does anything in the PG 13 change preclude writing
> a postgis_raster--unpackaged.sql script that could be applied with
> CREATE EXTENSION postgis_raster VERSION unpackaged;
> and would do perhaps nothing at all, or merely confirm that the
> right unpackaged things are present and are the right things...
> 
> ... from which an ALTER EXTENSION postgis_raster UPDATE TO 3.0;
> would naturally run the existing postgis_raster--unpackaged--3.0.sql
> and execute all of its existing ALTER EXTENSION ... ADD operations?
> 
> Has the disadvantage of being goofy, but possibly the advantage of
> being implementable in the current state of affairs.

Thanks for this hint, yes, seems to be technically feasible, as well
as doing packaging in the extension creation scripts. Only... this
would basically work around the intentionally removed syntax, which
Steven Frost was against (still unclear to me why)...

--strk;



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Improve handling of parameter differences in physical replication
Next
From: Pavel Stehule
Date:
Subject: Using stat collector for collecting long SQL