[postgis-users] [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 lr at pcorp.us
Tue Oct 27 20:42:28 PDT 2015


Steve,

Do you compile yourself? And do you use CREATE EXTENSION ..  If you do I think this change will work great for you.

If you don't it won't make a difference at all.

In this case raster is actually already a separate library from postgis.so/dll.  Not sure people realize that so there is no memory footprint gain separating them.  

The illusion that they are part of the same is just in the postgres extension glue.
You've always been able to compile without raster, you just couldn't install with CREATE EXTENSION then.  So this proposal is simply to fix that issue.  Nothing more.


> Also it seems like you should be able to create a meta package called "postgis" that installs all the extensions
>  or allow the user to install individual extensions via postgis-<name>. 
> I think the extension mechanism is still fairly new so maybe raising some of the issues with postgresql will help in the longer term.

This is something Sandro was proposing, but that is much more involved because you can never make a single postgis that depends on everything and having existing postgis back into that model to half itself is an  involved process both in development and explaining to people how they need to upgrade their database.  I'm personally not interested in going that route so not willing to put in the effort to do that.  I like raster as part of postgis, because it represents a uniquely different spatial type that works well with geometry whereas the other extensions we have simply just use the geometry type.  

That's why I say the difference should be embedded in the extension version (and not the name).  That's the only change I'm willing to put the effort in making if any change is done at all.

Moving forward each major feature is  its own extension as it has been postgis_topology, postgis_sfcgal, postgis_tiger_geocoder are all separate extensions packaged with the postgis package with postgis_sfcgal being an optional package because it has additional dependencies.

> Also it seems like you should be able to create a meta package called "postgis" that installs all the extensions or allow the user to install individual extensions via postgis-<name>. 
> I think the extension mechanism is still fairly new so maybe raising some of the issues with postgresql will help in the longer term.

Well you sorta can in PostgreSQL 9.6, you can create a skeleton postgis-mega extension that does nothing but says it requires postgis, postgis_topology, postgis_whatever

And then install with 

CREATE EXTENSION postgis-mega CASCADE;

And all dependencies would be installed.  However you'd still need to keep the versions in synch when you upgrade since the extension system doesn't currently have a way to specify which minimum version is required of an extension or alternative extensions.  That's something that has been discussed on postgres list in past.

Thanks,
Regina






-----Original Message-----
From: postgis-users [mailto:postgis-users-bounces at lists.osgeo.org] On Behalf Of Stephen Woodbridge
Sent: Tuesday, October 27, 2015 8:57 PM
To: postgis-users at lists.osgeo.org
Subject: Re: [postgis-users] [postgis-devel] postgis extension sans raster (only for folks who can't compile with raster support) - PSC Vote and developer/packager comments please

I for one have never used the raster functionality. I occasionally think about doing this or that with it, but have never gotten around to it. I also run Ubuntu 14.04 which has great support for the whole thing.

I like the idea of breaking postgis into multiple packages because:

* 99.99% of the time I only use the vector function
* I do use the address standardizer on a regular basis
* I have never used topology (except to experiment with it a few times)
* I have never used the raster stuff
* And I'm not sure what the CGAL stuff does

* installing only the sub-extensions that I need, would cut down on the clutter of functions when I'm browsing them for a signature using pgadmin

* while it probably does not matter, it just seems like smaller is better, less of a memory foot print, etc.

I can live with it either way.

Also it seems like you should be able to create a meta package called "postgis" that installs all the extensions or allow the user to install individual extensions via postgis-<name>. I think the extension mechanism is still fairly new so maybe raising some of the issues with postgresql will help in the longer term.

It doesn't sounds like there is any "good" solution, but I know from past efforts the GDAL is a huge beast to build with tons of other dependencies which is always a pain to resolve, especially if you have version specific requirements.

-Steve

On 10/27/2015 6:49 PM, Paragon Corporation wrote:
> How many folks are unable to compile postgis with raster or have a package that has no raster support and who REALLY REALLY want to be able to install postgis with:
>
> CREATE EXTENSION postgis;
>
> This is a repost of a conversation I started in PostGIS -develop which I probably should have cc'd PostGIS users on.  It seems not too many people on dev have issue compiling with GDAL support.
>
> The issue discussed is that since postgis raster is part of the 
> postgis extension, if people choose to compile without raster support 
> because they can't get GDAL to work (despite being discouraged), they 
> can not do
>
> CREATE EXTENSION postgis;
>
> They have to resort to the old way of using postgis contrib scripts to install.
>
> My proposition
> https://trac.osgeo.org/postgis/ticket/3338
>
>
> was still have a postgis that has raster support (as breaking it out at this point would be  headache particularly for the person who has to deal with the upgrade ramifications) and a big headache for people who use raster heavily as now they'd have two extensions to bother with.
>
> That said the proposition in a nutshell is this
>
> 1) Still have raster as default and you still need to explicitly ask 
> for --without-raster
> 2) If you ask for --without-raster, you'll get an extension called  
> "postgis" with no raster functions in it, but with an extension 
> version number that reads  2.3.0-no-raster
>
> So a query like this if you compiled without raster:
>
> SELECT  *
> FROM pg_available_extensions()
> WHERE name = 'postgis';
>
> Would read:
>
>    name   | default_version |                               comment
> ---------+-----------------+------------------------------------------
> ---------+-----------------+---------------------------
>   postgis | 2.3.0-no-raster     | PostGIS geometry and geography  spatial types and functions
> (1 row)
>
> Instead of:
>
>    name   | default_version |                               comment
> ---------+-----------------+------------------------------------------
> ---------+-----------------+---------------------------
>   postgis | 2.3.0           | PostGIS geometry, geography, and raster spatial types and functions
> (1 row)
>
>
> Which means people who have postgis without raster support can follow the world renowned instructions:
>
> CREATE EXTENSION postgis;
>
> Like everyone else and all the other postgis extensions postgis_topology, postgis_tiger_geocoder will be built as well.
>
> The main downside to this is
> 1) you have a postgresql postgis extension that may not have any raster functions and one that goes by same extension name postgis with raster support.
> Though I claim this is clear from the version number and description 
> :)
> 2) It does mean it s a bit easier for packager maintainers to package 
> a postgis without raster support which is both good and bad
> -- good for older systems where an old antiquated gdal is not readily available so they can still package a newer postgis for it.
> -- bad for users who rely on package maintainers and really want raster support as their package maintainer might just decide not to bother with raster.
>
> If there is enough interest, I will reopen the ticket I closed and 
> create and RFC as Paul Ramsey suggested to flesh out the complete details of this and how upgrading would work For folks coming from a postgis without raster non-extension version to a postgis without raster extension version.
>
> Thanks,
> Regina
> http://www.postgis.us
> http://postgis.net
>
>
>
>
> -----Original Message-----
> From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On 
> Behalf Of Sandro Santilli
> Sent: Tuesday, October 27, 2015 5:28 PM
> To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
> Subject: Re: [postgis-devel] postgis extension sans raster (only for 
> folks who can't compile with raster support) - PSC Vote and 
> developer/packager comments please
>
> On Tue, Oct 27, 2015 at 03:39:29PM -0400, Paragon Corporation wrote:
>> I've retracted.  Seems not enough interest for this and could lead to confusion.
>>
>> Or maybe I should have asked on postgis-users :)
>
> That's a good idea.
> Ask on postgis-users if there's any interest about being able to install postgis with no raster support.
>
> --strk;
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-devel
>
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-users
>

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




More information about the postgis-users mailing list