[postgis-devel] PSC vote Request: Make Geos 3.5 the default in PostGIS 2.2

Paul Ramsey pramsey at cleverelephant.ca
Mon May 25 05:19:56 PDT 2015


Would all this be moot if I just stubbed in a box-only implementation of <-> for geography to be used in earlier versions?
 


--  
http://postgis.net  
http://cleverelephant.ca


On May 25, 2015 at 4:46:12 AM, Paragon Corporation (lr at pcorp.us) wrote:
> 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.
>  
>  
>  
>  
> -----Original Message-----
> 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
> PostGIS 2.2
>  
> 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.
>  
> --strk;
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
>  
>  
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
>  




More information about the postgis-devel mailing list