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

Tue Mar 26 03:56:32 PDT 2019

Esteban,

We're not keeping C API stable. In 2.5 -> 3.0 many C functions got changed,
and that's likely not the end of it.

https://github.com/postgis/postgis/blob/svn-trunk/postgis/postgis_legacy.c

Some functions are implemented in SQL only (a large part of Raster?)

On Tue, Mar 26, 2019 at 1:47 PM Esteban Zimanyi <ezimanyi at ulb.ac.be> wrote:

> Dear Paul
>
> I fully understand. But what about an include file (e.g., PostgisAPI.h)
> containing all SQL functions from the API with a content such as the
> following one ?
>
> extern Datum transform(PG_FUNCTION_ARGS);
> extern Datum buffer(PG_FUNCTION_ARGS);
> extern Datum centroid(PG_FUNCTION_ARGS);
> ....
>
> That would already simplify the life of developers that build upon PostGIS
> since they can call these functions directly on the C code with e.g.,
>
> DirectFunctionCallX(FUNCTION, ARGS)
>
> and this does not add any dependency and have a better performance that
> sending SQL queries to call the corresponding function.
>
> Regards
>
> Esteban
>
> On Mon, Mar 25, 2019 at 3:30 PM Paul Ramsey <pramsey at cleverelephant.ca>
> wrote:
>
>> 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
>>
>> _______________________________________________
>> 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

-- 
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20190326/e5fa832d/attachment.html>