Re: [postgis-devel] About EXTENSION from UNPACKAGED on PostgreSQL 13

From: Sandro Santilli <strk(at)kbt(dot)io>
To: Chapman Flack <chap(at)anastigmatix(dot)net>, PostGIS Development Discussion <postgis-devel(at)lists(dot)osgeo(dot)org>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [postgis-devel] About EXTENSION from UNPACKAGED on PostgreSQL 13
Date: 2020-02-27 08:58:21
Message-ID: 20200227085821.GB6597@liz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 27, 2020 at 09:32:24AM +0100, Sandro Santilli wrote:
> 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)...

NOTE: my suggestion was to directly have CREATE EXTENSION do the
packaging, which would give the same level of security as the
workaround suggested here, but with less hops.

--strk;

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Konstantin Knizhnik 2020-02-27 09:03:54 Re: Yet another vectorized engine
Previous Message Antonin Houska 2020-02-27 08:51:41 Re: WIP: Aggregation push-down