[postgis-tickets] [PostGIS] #3889: Support --without-geos switch

PostGIS trac at osgeo.org
Sun Oct 8 12:56:37 PDT 2017


#3889: Support --without-geos switch
----------------------+---------------------------
  Reporter:  robe     |      Owner:  pramsey
      Type:  defect   |     Status:  new
  Priority:  medium   |  Milestone:  PostGIS 2.5.0
 Component:  postgis  |    Version:  trunk
Resolution:           |   Keywords:
----------------------+---------------------------
Description changed by robe:

Old description:

> This was a request from Darafei Praliaskouski (Komzpa) made on IRC on
> behalf of Postgres Professional (https://postgrespro.com/)
>
> Normally I'd laugh at such a request, but I'd like to do it for a couple
> of reasons especially if Komzpa is willing to put in the sweat to make it
> happen.
>
> 1. Postgres Professional (is lead by Oleg Bartunov and Teodor Sigaev)
> which many long standing folks in PostGIS community might recognize as
> the faces behind GiST (which makes PostGIS so fast) and  Full-Text search
> in addition to index improvements on JSON.
>
> 2.  They need it for a very good cause. They need a lighter-weight
> PostGIS that can be used easily, so they can defend the security of it to
> the Russian Government.
>
> GEOS is too big of a creature for them to audit and approve.
>
> 3. I forsee this as an easy way for new developers to get up to speed
> contributing to PostGIS since the requirements to compile will be lower.
>
> My proposal is as follows.
>
> If postgis is compiled --without-geos  (we assume if that config is not
> present then we still require geos), much like we do --without-raster,
> then all GEOS functions will be stubbed and throw an error, something
> like
>

> {{{
> Requires GEOS, you need to recompile your PostGIS with GEOS support to
> use this function
> }}}
>
> 4. However the following function ST_Intersects will still be available,
> but instead of using GEOS would piggy back on _ST_DWithin, much like what
> geography type does already.  We  should do this on the C-side so no
> upgrading needs to be done if people recompile / --without-geos  or with
> geos.

New description:

 This was a request from Darafei Praliaskouski (Komzpa) made on IRC on
 behalf of Postgres Professional (https://postgrespro.com/)

 Normally I'd laugh at such a request, but I'd like to do it for a couple
 of reasons especially if Komzpa is willing to put in the sweat to make it
 happen.

 1. Postgres Professional (is lead by Oleg Bartunov and Teodor Sigaev)
 which many long standing folks in PostGIS community might recognize as the
 faces behind GiST (which makes PostGIS so fast) and  Full-Text search in
 addition to index improvements on JSON.
 Postgres Professional has contributed development to PostgreSQL (e.g.
 index support for regex, new work on ANSI-SQL JSON support and numerous
 other things too many to count)

 2.  They need it for a very good cause. They need a lighter-weight PostGIS
 that can be used easily, so they can defend the security of it to the
 Russian Government.

 GEOS is too big of a creature for them to audit and approve.

 3. I forsee this as an easy way for new developers to get up to speed
 contributing to PostGIS since the requirements to compile will be lower.

 My proposal is as follows.

 If postgis is compiled --without-geos  (we assume if that config is not
 present then we still require geos), much like we do --without-raster,
 then all GEOS functions will be stubbed and throw an error, something like


 {{{
 Requires GEOS, you need to recompile your PostGIS with GEOS support to use
 this function
 }}}

 4. However the following function ST_Intersects will still be available,
 but instead of using GEOS would piggy back on _ST_DWithin, much like what
 geography type does already.  We  should do this on the C-side so no
 upgrading needs to be done if people recompile / --without-geos  or with
 geos.

--

--
Ticket URL: <https://trac.osgeo.org/postgis/ticket/3889#comment:3>
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.


More information about the postgis-tickets mailing list