Re: postgis for beta releases

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Devrim Gündüz <devrim(at)gunduz(dot)org>
Cc: pgsql-pkg-yum(at)postgresql(dot)org, Paul Ramsey <pramsey(at)cleverelephant(dot)ca>
Subject: Re: postgis for beta releases
Date: 2020-09-12 21:56:06
Message-ID: 20200912215606.GR18552@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-pkg-yum

On Tue, Jul 28, 2020 at 11:14:43AM +0100, Devrim Gündüz wrote:
> On Tue, 2020-07-21 at 13:16 -0500, Justin Pryzby wrote:
> > As I mentioned, I think postgis30 should *also* be built for v13, and
> > postgis31 should *maybe* be built for v12:
>
> Pushing them to v11 and v12 *testing* repos in an hour or so.

Note, I still suggest that postgis30 and postgis31 should *both* be built for
postgres13 and (at least) postgres12.

I've done a couple test upgrades from pg12 to 13, some using pg_dump/restore,
some using pg_upgrade. In both cases, I first had to do:

|DROP AGGREGATE st_union(geometry);
|DROP FUNCTION pgis_geometry_union_transfn;

I guess postgis30 and 31 are "compatible enough" that I was able to restore a
postgis30 DB into a DB with only postgis31 available.

Normally, I'd have to do a "rolling upgrade", either:
(pg12+gis30) => (pg12+gis31) => (pg13+gis31), or:
(pg12+gis30) => (pg13+gis30) => (pg13+gis31).

I guess this is related to postgis commit 75a044c61:

|Author: Paul Ramsey <pramsey(at)cleverelephant(dot)ca>
|Date: Fri Oct 4 18:25:46 2019 +0000
| Restore ST_Union() aggregate signature and re-work...

--
Justin

In response to

Responses

Browse pgsql-pkg-yum by date

  From Date Subject
Next Message Justin Pryzby 2020-09-14 12:56:36 pre-release packages
Previous Message Christoph Berg 2020-09-11 09:16:18 WorkingDirectory=~ on CentOS 7