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

Raúl Marín Rodríguez rmrodriguez at carto.com
Mon Mar 25 04:34:25 PDT 2019


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


More information about the postgis-devel mailing list