From: | Sandro Santilli <strk(at)kbt(dot)io> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Stephen Frost <sfrost(at)snowman(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-26 15:06:14 |
Message-ID: | 20200226150614.GC27646@liz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Feb 26, 2020 at 03:35:46PM +0100, Daniel Gustafsson wrote:
> > On 26 Feb 2020, at 15:13, Sandro Santilli <strk(at)kbt(dot)io> wrote:
>
> > On pgsql-hackers we only want to find a future-proof way to "package
> > existing objects into an extension".
>
> What is the longterm goal of PostGIS, to use this as a stepping stone to reach
> a point where no unpackaged extensions exist; or find a way to continue with
> the current setup except with syntax that isn't going away?
No unpackaged extension seems like a good goal in the long term.
> Overloading the same syntax for creating packaged as well as unpackaged
> extensions sounds like the wrong path to go down.
So what other options would we have to let people upgrade a running
postgis or postgis_raster outside of the EXTENSION mechanism ?
--strk;
From | Date | Subject | |
---|---|---|---|
Next Message | Alastair Turner | 2020-02-26 15:16:11 | Re: Parallel copy |
Previous Message | Tom Lane | 2020-02-26 15:03:14 | Re: Resolving the python 2 -> python 3 mess |