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

[Esteban Zimanyi]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20190326/13b4b2b0/attachment-0001.html>