[postgis-devel] PSC vote Request: Make Geos 3.5 the default in PostGIS 2.2
lr at pcorp.us
Mon May 25 04:46:03 PDT 2015
Well I was only thinking of the KNN geography because that changes the
operator class from 9.4 to 9.5 and also introduces new operators.
I thought the <-> was under the hood (used the same function in both cases)
so when they upgrade to 9.5 that would be a non-issue.
By binary -- I meant to say in-place upgrade where the sql definitions of
the functions don't get upgraded by a new CREATE EXTENSION call like backup
and restore does.
Binaries change of course since a 9.4 binary would never work on a 9.5
install anyway, but yah having postgis_full_version expose the version it
was built from would solve that problem. But that would have to be a
plpgsql embedded solution since the binaries would be 9.5
Thogh the function definitions came from a 9.4 upgrade.
From: postgis-devel-bounces at lists.osgeo.org
[mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Sandro Santilli
Sent: Monday, May 25, 2015 3:15 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] PSC vote Request: Make Geos 3.5 the default in
On Sun, May 24, 2015 at 10:24:11AM -0400, Paragon Corporation wrote:
> strk, Paul - any thoughts on how to deal with that one? When you run
> pg_upgrade, since it's doing a binary upgrade, I don't think CREATE
> EXTENSION is run so the functions just get pulled over.
We're talking about <-> semantic changing based on PostgreSQL version, right
? That's not the only case of PostgreSQL version dependent behavior, another
one is presence or absence of the whole index-assisted KNN.
The only idea I have about this is to expose the version of PostgreSQL
PostGIS was built against so that postgis_full_version() can complain about
it and recommend a re-build/re-install. Then we need to also allow for
upgrades between same versions as we already do with the "next" trick.
postgis-devel mailing list
postgis-devel at lists.osgeo.org
More information about the postgis-devel