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

[Paragon Corporation]

Yap.  Then I can document it too and have my garden tester test it :)

Thanks,
Regina

-----Original Message-----
From: Paul Ramsey [mailto:pramsey at cleverelephant.ca] 
Sent: Monday, May 25, 2015 8:20 AM
To: PostGIS Development Discussion; Paragon Corporation
Subject: Re: [postgis-devel] PSC vote Request: Make Geos 3.5 the default in PostGIS 2.2

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
>