[postgis-devel] PostGIS 3 and MobilityDB

[Regina Obe]

I’m not so much concerned about compile time compatibility as I am concerned about runtime compatibility.

Since PostGIS 3.0, we stripped the minor version so for general package builds, the lib file will be called simply postgis-3.<lib ext>. (where lib ext can be .so, dylib, .dll, .whaever os suffix).  This was to ease upgrade pain.

 

All we guarantee between postgis-3s (3.0, 3.1, 3.2) is that any functions exposed via the SQL API from 3.0 will be present in 3.1, 3.2 and so on. Though that said they could be marked as deprecated or no longer functional.

 

What I’m concerned about here is someone that is using both MobilityDb and PostGIS is going to try to upgrade their PostGIS or their mobilityDB and if you are relying on functions we don’t expose in the SQL API (Datum form) and we rip them out between versions (even in a micro we could do that), it will be a packaging and upgrade mess because the new postgis-3.<lib ext> will be incompatible with whatever MobilityDb was compiled against and then the packager would then have to make sure they recompile MobilityDB or don’t allow PostGIS upgrade.

 

I’m probably more concerned than I should be about the issue but I feel it will become more of a concern the more you depend on PostGIS functions, so I’d keep such use of what I call (the private ones) to very small (or non-existent).  Such things you are better copying the relevant code than relying on the PostGIS code to not change.

 

 

From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Esteban Zimanyi
Sent: Friday, July 9, 2021 4:07 AM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Cc: Mahmoud Sakr <m_attia_sakr at yahoo.com>; mohamed sayed <mohamed_bakli at aun.edu.eg>; SCHOEMANS Maxime <Maxime.Schoemans at ulb.be>
Subject: Re: [postgis-devel] PostGIS 3 and MobilityDB

 

Dear Regina

 

Many thanks for restarting the issue of detecting PostgreSQL and PostGIS versions, we will look into it.

 

Concerning C compatibility, we already need to cope with this for PostgreSQL. I have collected below some pieces of code we need to put to cope with various PostgreSQL versions (this is not exhaustive). There is no problem for us to do similar things for changes in PostGIS.

 

#if MOBDB_PGSQL_VERSION < 110000
  pq_sendint(buf, (uint32) ts->count, 4);
#else
  pq_sendint32(buf, ts->count);
#endif

#if MOBDB_PGSQL_VERSION < 130000
#include <access/tuptoaster.h>
#else
#include <access/heaptoast.h>
#endif
#if MOBDB_PGSQL_VERSION < 110000
#include <catalog/pg_collation.h>
#include <catalog/pg_operator.h>
#else
#include <catalog/pg_collation_d.h>
#include <catalog/pg_operator_d.h>
#endif

#if MOBDB_PGSQL_VERSION >= 120000
#include <utils/float.h>
#endif

#if MOBDB_PGSQL_VERSION < 110000
  RangeType *range = PG_GETARG_RANGE(1);
#else
  RangeType *range = PG_GETARG_RANGE_P(1);
#endif

#if MOBDB_PGSQL_VERSION < 140000
/**
 * Returns the union of the range values. If strict is true, it is an error
 * that the two input ranges are not adjacent or overlapping.
 *
 * @note Function copied verbatim from rangetypes.c since it is static before 
 * PostgreSQL version 14.
 */
static RangeType *
range_union_internal(TypeCacheEntry *typcache, RangeType *r1, RangeType *r2,
  bool strict)
{
  [...]
}
#endif

#if MOBDB_PGSQL_VERSION < 110000
PG_FUNCTION_INFO_V1(temporal_gist_decompress);
/**
 * GiST decompress method for temporal values (result in a period)

 *
 * The decompress method is optional after PostgreSQL version 11
 */
PGDLLEXPORT Datum
temporal_gist_decompress(PG_FUNCTION_ARGS)
{
  GISTENTRY  *entry = (GISTENTRY *) PG_GETARG_POINTER(0);
  PG_RETURN_POINTER(entry);
}
#endif

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20210709/9da680da/attachment-0001.html>