[postgis-tickets] [PostGIS] #3888: Split core and raster extensions

[PostGIS]

#3888: Split core and raster extensions
--------------------------+---------------------------
  Reporter:  strk         |      Owner:  pramsey
      Type:  enhancement  |     Status:  new
  Priority:  medium       |  Milestone:  PostGIS 2.5.0
 Component:  postgis      |    Version:  trunk
Resolution:               |   Keywords:
--------------------------+---------------------------

Comment (by robe):

 -1 the more I think about it, the more I am against splitting
 postgis_raster from postgis.  I'm +1 on allowing users who have --witout-
 raster have an extension build
 as long as the version name is different, something like 2.5.0noraster.

 The reason is

 1. Raster would be the only type not in postgis extension that has index
 bindings that piggy back on PostGIS geometry and also has GUCs stamped
 with postgis. and all it's functions also have @extschema@ qualified which
 presumes it is installed in same schema as postgis.

 Having it as a separate extension could conceivably allow people to
 install it in a separate schema other than where they installed postgis,
 which would make the extension unusable.

 2. All your proposals thus far break-backward compatibility in a painful
 way.
 Like if a user is restoring a raster backup from 2.4.0, how are you going
 to deal with that.  Your idea of unpackaging and leaving it up to the user
 to repackage is very disturbing.

 3. I like having my raster in postgis :) I use it and why are you making
 me do more work just to satisfy your flawed sense of beauty.  Having
 postgis_raster as a separate extension is not beautiful to me.  It just
 makes my life harder and the life of everyone that uses raster harder.

 4. With your proposal I have do do

 {{{

 ALTER EXTENSION postgis UPDATE;
 ALTER EXTENSION postgis_raster UPDATE;
 }}}


 If people really don't want raster, they should compile --without-raster

 and they should get a postgis version that says 2.5.0noraster.

 If people want some databases to have raster and some not, then they
 should do


 {{{
 CREATE EXTENSION postgis VERSION "2.5.0noraster";
 }}}


 If they then decide to add raster and they have the full-features version
 of postgis, they would do


 {{{
 ALTER EXTENSION postgis VERSION "2.5.0noraster";
 }}}

 users who just have --without raster can do


 {{{
 ALTER EXTENSION postgis UPDATE;
 }}}



 The other nice thing about this, is going this way, it's much easier to
 fix in 3.0 when PostgreSQL extension machinery will be improved and it
 doesn't break backward compatibility now.  What you are asking for to me
 should really be done 3.0 if we think it's necessary.

 To solve the immediate need of having extension without-raster, as I have
 said time and time again, the easiest way (that doesn't break backward-
 compatibility) is to encode it in the extension version.


 To me encoding it in the extension version is the same as saying Ubuntu
 Server 11.04 vs.  Ubuntu Desktop 11.04.  They are essentially the same
 thing but one has a head and one does not.

--
Ticket URL: <https://trac.osgeo.org/postgis/ticket/3888#comment:2>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.