postgis extension that returns not supported for all Raster functions if raster not available

[robe]

Was

talking on IRC with astrodog and it seems they are having a hard time

getting raster in the FreeBSD packages because of all the dependencies GDAL brings in which a user may not have.

The easiest option which he proposed which I think we can swing is to still have a PostGIS extension that zeros out raster if not available. Just returns a not supported note similar to what we do with ST_GeoJSON and several GEOS functions if your GEOS is not new enough.

Here is bit of IRC dialog for context

23:39] <astrodog> We build gdal as another package, with pretty 
broad support for formats.
[23:39] <astrodog> That way things just work for people.
[23:39] <robe2> and disable everything except some key ones like 
sqlite, odbc, curl
[23:40] <robe2> I even disable postgres
[23:40] <astrodog> But PostGIS brings in GDAL, which brings in a 
pile of other things.
[23:40] <astrodog> None of it is bad if you build from source... 
it's the binary packages that cause problems.
[23:41] <robe2> one more reason not to have a shared liblwgeom :)
[23:41] <robe2> astrodog: so you can't build an isolated gdal sits
 in postgres bin?
[23:42] <robe2> on windows always searches in postgres bin first
[23:42] <robe2> so I can override system dlls by replacing with my
 own version
[23:42] <robe2> not sure how it works on unix/linux
[23:43] <astrodog> robe: If you guys bundle it, I can. If you 
don't, I'm expected to use whatever the gdal port does, that way users 
can set whatever gdal options they want.
[23:43] <robe2> so if we included gdal source as part of our dist 
package?
[23:45] <robe2> pl/v8 (not sure if they still do have to check) 
included v8 source zip as part of theres
[23:45] <astrodog> Sure. Then it's just some thing you guys 
included... and any issues it creates would be sent up to PostGIS trac. 
*grin*
[23:45] <robe2> cause the v8 upstream was kinda flaky (I mean you 
hit a bad version and you are screwed)
[23:48] <robe2> astrodog: so if you have gdal already is the issue
 because depending on user installing, they might have a different gdal 
with not all the dependencies available
[23:49] <robe2> I got the impression from listening to 
devrimgunduz that was his pain
[23:49] <robe2> and why EL 5, CentOS 5 he was very apologetic for
[23:49] <astrodog> Yeah.
[23:49] <astrodog> For us... we install GDAL with a huge pile of 
things, so that the various bits that depend on it can all use one 
version.
[23:50] <astrodog> But it means requiring GDAL is a fairly large 
requirement.
[23:50] <robe2> I wonder how hard it would be to get GDAL to do 
run-time load like they do with proj already
[23:50] <robe2> that seems like the fundamental issue
[23:51] <robe2> astrodog: do you built spatialite and rasterlite
[23:51] <robe2> as I recall rasterlite relies on gdal I think
[23:51] <robe2> so would have similar issue
[23:52] <astrodog> Yeah, it does.
[23:52] <robe2> so you have same issue with it?
[23:53] <astrodog> Yeah, but with rasterlite, people know they're 
in for it.
[23:53] <robe2> one thing I always wanted was for people to be 
able to swap out the gdal I have with a beefier one
[23:53] <astrodog> The issue we run into with PostGIS is that the 
SQL method isn't as well documented... so we get PRs saying "Loading the
 extension doesn't work!"
[23:54] <robe2> well we could document that better I guess
[23:54] <robe2> I didn't like it cause it required too much 
explaining
[23:54] <astrodog> It's not so much you guys, as every tutorial on
 the planet skips over that option. :P
[23:54] <robe2> like find where your files are stored -- and I 
lost 90% of the audience at that point
[23:54] <astrodog> Be nice if the extension had a way to tell if 
it had raster support or not, and act accordingly.
[23:55] <robe2> and had to digress into if you are on this - its' 
here , if you are on that it's here etc
[23:55] <astrodog> *nod*
[23:56] <robe2> yah but then it wouldn't be the same extension
[23:56] <robe2> we could create a postgis_no_raster extension
[23:56] <astrodog> Could the extension stub out the raster bits if
 they aren't there?
[23:57] <astrodog> So the function exists, it just always returns 
not supported.
[23:57] <astrodog> :P
[23:57] <robe2> but the problem is the extension model doesn't 
have a way to say something like requires: postgis or postgis_no_raster;
[23:57] <robe2> So you'd have issues with like you can't install 
postgis_sfcgal, pgrouting etc.
[23:57] <robe2> astrodog: ah didn't think about that
[23:57] <robe2> yah it could
[23:57] <robe2> that's a great idea
[23:58] <robe2> we do that already for some functons like json and
 geos if you are running a lower geos
[23:58] <robe2> I'll ticket it

[strk]

I thought we had a ticket for this but could not find one. My idea was that we should have these extensions:

• postgis_core
• postgis_raster depends on postgis_core
• postgis_topology depends on postgis_core
• postgis_sfcgal depends on postgis_core
• (postgis depends on postgis_core and postgis_raster) for backward compatibility

How to get there is still to be found out, especially when it comes to upgrading an existing system.