[postgis-devel] PostGIS 3 and MobilityDB

[Esteban Zimanyi]

Dear Regina

Regarding the way we detect PostgreSQL, according to my understanding we
are doing similar things as done in PostGIS. In the configure file of
PostGIS 3.1.2 it is stated

  PGSQL_FULL_VERSION=`"$PG_CONFIG" --version`
  PGSQL_MAJOR_VERSION=`echo $PGSQL_FULL_VERSION | sed
's/[^0-9]*\([0-9]*\).*/\1/'`
  PGSQL_MINOR_VERSION=`$PG_CONFIG --version | sed
's/[^0-9]*\([0-9]\)\.\([0-9]\).*/\2/'`

In our CMakeLists.txt we do

  execute_process(COMMAND ${PGCONFIG} --version OUTPUT_VARIABLE
PG_VERSION_STRING OUTPUT_STRIP_TRAILING_WHITESPACE)

and continue stripping the major and minor versions in a less efficient way
than you do. There is no problem in reusing your recipe for doing that.

Regarding the PostGIS issue, as I commented in your PR over github
---- (copied from github) ---

Actually, we use postgis-2.5.so just to ensure the version, we don't do
anything with it. I commented the following lines in the CMakeLists.txt and
everything works, the tests pass without any problem.

find_library(HAS_LWGEOM lwgeom)
if (HAS_LWGEOM)
MESSAGE(STATUS "Found LWGEOM at ${HAS_LWGEOM} - compiling with PostGIS
support")
--> if(NOT EXISTS "${PostgreSQL_EXTLIB_DIR}/postgis-2.5.so")
--> message(FATAL_ERROR "Could not find postgis-2.5.so; only PostGIS 2.5 is
currently supported")
--> endif()
else()
message(FATAL_ERROR "Could not find lwgeom; ")
endif ()
---- (copied from github) ---
we did that to avoid the use of PostGIS 3 with MobilityDB until we solve
this issue (as we are discussing in the current thread). As soon as you
tell us how to solve this we will change this immediately.

Many many thanks for your continuous support !

Esteban

On Fri, Jul 9, 2021 at 8:27 AM Regina Obe <lr at pcorp.us> wrote:

> A side note, I think you need to change the way you are detecting
> PostgreSQL.  It just doesn’t work for me and suspect it will be an issue
> for anyone with multiple PostgreSQL installs or non-standard paths  – as I
> had mentioned here - https://github.com/MobilityDB/MobilityDB/pull/20 .
> You should be using the
>
> CMAKE PostgreSQL package to detect PostgreSQL.  I always end up having to
> copy pgRouting code in so the PostgreSQL detection works right.
>
>
>
> As I recall compiling MobilityDB a while ago it has both a dependency to
> liblwgeom as well as the PostGIS lib.
>
> The dependency of PostGIS lib is a little troubling as I mentioned here
>
>
>
> https://github.com/MobilityDB/MobilityDB/issues/16
>
>
>
> Even the extensions packaged with PostGIS don’t have a direct dependency
> to PostGIS lib just to liblwgeom.
>
>
>
> So not even a parallel branch will work here unless you change how you are
> doing things and what to change is unclear to me.  The issue with depending
> on PostGIS lib is we only guarantee SQL API compatibility across minor
> versions, not C-API.  Meaning if the function isn’t exposed via the SQL
> API, we don’t need to worry about it as PostgreSQL upgrade would not care
> as it only fails if it tries to call a function that is referenced in an
> SQL API function.
>
>
>
> That said if you must rely on PostGIS lib all your postgis.h dependencies
> should only be Datum ones and any others will make your code brittle to
> PostGIS changes.
>
> I’m thinking for the liblwgeom dependency you should be able to use
> librtopo for that. Still not clear to me why you can’t, but we can discuss
> in dev meeting.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20210710/1a8e6ff7/attachment.html>