[postgis-devel] postgis extension sans raster (only for folks who can't compile with raster support) - PSC Vote and developer/packager comments please

[Paragon Corporation]

Slight clarification, when I say

postgis version number

I meant the extension version number

Our 

SELECT postgis_full_version(); 

Denotes raster and postgis separately so the version would still be 2.2.0, just the extension version number scripts would be different.

-----Original Message-----
From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Paragon Corporation
Sent: Saturday, October 24, 2015 2:14 PM
To: 'PostGIS Development Discussion' <postgis-devel at lists.osgeo.org>
Subject: [postgis-devel] postgis extension sans raster (only for folks who can't compile with raster support) - PSC Vote and developer/packager comments please

One FreeBSD packager brought up that they can't compile PostGIS with raster support because of the QT dependency it drags in among others.  I still don't quite understand why that's a big deal.

Anyway people complain because then they can't install postgis with 

CREATE EXTENSION postgis;


Like everyone else.  I've seen similar complaints with Homebrew folks who compile their own.

Rather than splitting raster out of postgis as many have proposed and causing an upgrade mess for everybody , I propose this:

https://trac.osgeo.org/postgis/ticket/3338

In a nutshell: encode the lack of raster in the postgis version number rather than the extension name itself.  This approach has the following benefits (repeated from the ticket):
We still have raster as the default behavior and people still need to say explicitly without-raster during configure.


1)    Most extensions that rely on PostGIS just use the vector portion, so
keeping the name the same they can continue on without having to change their requires statement (changing requires is huge mess particularly for extensions like pgRouting since then they'd have a different requires for new PostGIS than older and they support 3 versions of each PostGIS minor)

Not to mention a huge mess for all the documentation already out there.

 2)   We have the same set of instructions for everybody: 

CREATE EXTENSION postgis;


3)    With the version differentiator it's trivial to upgrade a half-baked
version 2.3.0-no-raster to a full yummy 2.3.0 version. We just add upgrade scripts to go from 2.3.0-no-raster to 2.3.0 regular postgis  (which is pretty trivial exercise)

4)    Similarly we can have a 2.3.0--2.3.0-no-raster that gets installed if
you compile without raster support. Which will drop all the raster functions during the upgrade. 

5)    It's fairly trivial to do compared to returning not supported I was
thinking of before. 


What do folks think about this? Am I nuts or is this a great idea?

If all are for it, I'm willing to do the work to make it happen for 2.3.0

Thanks,
Regina




_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-devel