[postgis-devel] Developing External Functions Using PostGIS Types with postgis-devel

[Paul Ramsey]

Harsh but true.
When building “dependent” things for PostGIS I like to get the dependency down to a bare minimum. So, call SQL functions, in SQL. And use EWKB as the transport layer rather than assuming I know what the PostGIS serialization format it. You can see an example in pointcloud_postgis. By using EWKB I can integrate with PostGIS via casts through bytea. For something computationally expensive like a spanning tree algorithm, you probably won’t even notice the slight extra overhead of the one spare format to transit through.
You do end up needing your own WKB reader/writer on your side, but it’s not the end of the world.
P.

> On Mar 25, 2019, at 4:34 AM, Raúl Marín Rodríguez <rmrodriguez at carto.com> wrote:
> 
> Hi,
> 
> Postgis was never intented to be a building block that you could use
> to build C code on top; the only thing we guarantee (or try to) is
> that we won't break your SQL code on an upgrade*. In fact in the next
> release (3.0), the default will be to not install neither headers nor
> liblwgeom.so. The main reasoning behind this is that we don't keep
> internal ABI stability, so you'd depend on something that can break
> even within minor releases and these changes won't be documented.
> 
> * This means that we also keep the exposed C API, since removing those
> functions would break installations.
> 
> If you only need the functionality within liblwgeom, I'd recommend you
> to have a look at https://git.osgeo.org/gitea/rttopo/librttopo, but
> for the Postgres part (which both of you seem to require) there isn't
> an alternative to creating the functionality directly inside Postgis.
> 
> On Mon, Mar 25, 2019 at 12:24 PM Esteban Zimanyi <ezimanyi at ulb.ac.be> wrote:
>> 
>> Dear all
>> 
>> I have similar problems when building MobilityDB, a temporal extension of PostGIS that takes care of the temporal aspects and fully delegates all spatial functionality to PostGIS. I ended up adding a file PostGIS.h in which I put all declarations of PostGIS functions that are not in liblwgeom.h, e.g.,
>> 
>> extern void srid_is_latlong(FunctionCallInfo fcinfo, int srid);
>> ....
>> 
>> but also the functions from the API that I call directly
>> 
>> extern Datum transform(PG_FUNCTION_ARGS);
>> extern Datum buffer(PG_FUNCTION_ARGS);
>> extern Datum centroid(PG_FUNCTION_ARGS);
>> ...
>> 
>> Regards
>> 
>> Esteban
>> 
>> 
>> On Mon, Mar 25, 2019 at 12:06 PM Adam Dadvar <adam.dadvar at gmail.com> wrote:
>>> 
>>> Hi All,
>>> 
>>> I have been trying to develop a separate function that builds on top of the PostGIS types. Effectively what I'm trying to do is use MultiLineStrings as a network to compute a minimum spanning tree. The end of each line is a node in this case.
>>> I think I have a basic understanding of how your code-base works but I am having issues where functions that I think should be available in postgis-devel are not.
>>> 
>>> I know that liblwgeom.h is included in the postgis-devel library which provides the basic types and some utility functions, but for example, I want to input a MultiLineString (LWMLINE in the C code) so I use PG_GETARG_GSERIALIZED_P(0), but this is not included in liblwgeom.h. For that I can write my own function that does that from PG_DETOAST_DATUM, but for other functions it gets much more complicated - in order to convert the GSERIALIZED object I can either write my own function (which would take a long time) or just use the lwgeom_from_gserialized function that has already been written, however this function is not included in postgis-devel and has a large number of dependencies.
>>> 
>>> I could just copy all of the header files from the source code and include them in my file but I'd prefer to just be able to say that the file depends on postgis-devel and then it can be compiled (this file needs to be rolled out to AWS in future).
>>> 
>>> I understand that the recommendation might just be to produce the MST function within the PostGIS code-base, which I'd be open to do. It just seems strange that the postgis-devel library is basically unusable if you want to use it to extend PostGIS. Does anyone have any pointers on how to proceed?
>>> 
>>> All advice is appreciated,
>>> Adam Dadvar
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>> 
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/postgis-devel
> 
> 
> 
> -- 
> Raúl Marín Rodríguez
> carto.com
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel