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;
