[postgis-devel] Allowing use of PostGIS EXTENSION w/out raster

[Regina Obe]

Slight correction to my comment about packaging a fully functional postgis

> The one with raster you can either call postgis or  postgis_raster (and have it depend on postgis_core).  If you call this one postgis, no one has to change what they are doing to install.
> That one , you would register, depends on postgis_core, and in addition include the extension script files, that don't end with --noraster.sql

You'd also need to copy over the raster2pgsql and rtpostgis lib to the package you call postgis (or postgis_raster)

-----Original Message-----
From: Regina Obe [mailto:lr at pcorp.us] 
Sent: Sunday, October 08, 2017 11:30 PM
To: 'PostGIS Development Discussion' <postgis-devel at lists.osgeo.org>; 'Sandro Santilli' <strk at kbt.io>
Cc: 'PostGIS Users Discussion' <postgis-users at lists.osgeo.org>
Subject: RE: [postgis-devel] Allowing use of PostGIS EXTENSION w/out raster


Sandro Santilli <strk at kbt.io>> writes:

>> I'm starting this thread to gather opinions about two current 
>> proposals for allowing people to use POSTGIS via the EXTENSION 
>> mechanism but w/out being forced to also have RASTER.
>>
>> The proposals are:
>>
>>  1) Move raster to its own extension "postgis_raster"
>>     See https://trac.osgeo.org/postgis/ticket/3888
>>
>>  2) Provide two versions of extension "postgis"
>>     See https://trac.osgeo.org/postgis/ticket/3890

> Yes - packaging!

> So two questions:

 >  what about the case where there are two users in one database?  Is
  > that already a situation where the DBA has to choose what's installed,
  >  so if either wants raster there is raster and that's ok?

Yes regardless which option you go with that is always the case.  Neither proposal has benefit in that regard.

  >  how should this be packaged?  Is there one postgis package with two
  >  extensions, or one postgis-noraster and one postgis-raster?  Or is
  > there a postgis package that doesn't depend on gdal and a
  >  postgis-raster that does?

> If there are to be two packages, then perhaps there should be two distribution tarballs.

Both approaches can accommodate.  I think approach 2 is better for packagers because a user can more cleanly migrate to a postgis that doesn't have raster without knowing anything.

If you wanted to make two packages, one that has GDAL dependencies (which means raster option), you would

compile PostGIS as usual, copy only the extension files  that end in noraster.sql and the postgis-.. lib, shp2pgsq  to a package you call "postgis_core"  or whatever you name it.

The one with raster you can either call postgis or  postgis_raster (and have it depend on postgis_core).  If you call this one postgis, no one has to change what they are doing to install.

That one , you would register, depends on postgis_core, and in addition include the extension script files, that don't end with --noraster.sql



> And then:

 >  what is the point of not "forcing" people to have raster?  What bad  > thing happens now when someone installs postgis and there is raster  >  capability in the db, but nobody ever puts any rasters in?  How does  >  not installing raster change what happens in a way that solves any  >  problems?

> I think the answer is that if nothing in pgsql depends on gdal, then you don't have to have gdal on the machine, and gdal library changes don't make you do anything.  But I'm not really sure that's the point.

That is one of the points.  The other point is that raster introduces like at least 100 more functions, and some people Steve Woodbridge , strk come to mind, are bothered about seeing more functionality in their database than they need.


My main reasons for offering such a proposition even is lots of folks who build their own PostGIS but don't want raster support but still want the convenience of CREATE EXTENSION are being inconvenienced.
That's the major reason for me to propose option (2), it provides those folks with CREATE EXTENSION without inconveniencing others and also has the side benefit of allowing people to choose whether or not to have raster installed in their database.

I am against option (1) because as it stands it breaks backward-compatibility in a huge way, both in upgrading your database and having different instructions for enabling raster support in your database.

Thanks,
Regina