<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>I’m not so much concerned about compile time compatibility as I am concerned about runtime compatibility.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> postgis-devel [mailto:postgis-devel-bounces@lists.osgeo.org] <b>On Behalf Of </b>Esteban Zimanyi<br><b>Sent:</b> Friday, July 9, 2021 4:07 AM<br><b>To:</b> PostGIS Development Discussion <postgis-devel@lists.osgeo.org><br><b>Cc:</b> Mahmoud Sakr <m_attia_sakr@yahoo.com>; mohamed sayed <mohamed_bakli@aun.edu.eg>; SCHOEMANS Maxime <Maxime.Schoemans@ulb.be><br><b>Subject:</b> Re: [postgis-devel] PostGIS 3 and MobilityDB<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>Dear Regina<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Many thanks for restarting the issue of detecting PostgreSQL and PostGIS versions, we will look into it.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>#if MOBDB_PGSQL_VERSION < 110000<br> pq_sendint(buf, (uint32) ts->count, 4);<br>#else<br> pq_sendint32(buf, ts->count);<br>#endif<br><br>#if MOBDB_PGSQL_VERSION < 130000<br>#include <access/tuptoaster.h><br>#else<br>#include <access/heaptoast.h><br>#endif<br>#if MOBDB_PGSQL_VERSION < 110000<br>#include <catalog/pg_collation.h><br>#include <catalog/pg_operator.h><br>#else<br>#include <catalog/pg_collation_d.h><br>#include <catalog/pg_operator_d.h><br>#endif<br><br>#if MOBDB_PGSQL_VERSION >= 120000<br>#include <utils/float.h><br>#endif<br><br>#if MOBDB_PGSQL_VERSION < 110000<br> RangeType *range = PG_GETARG_RANGE(1);<br>#else<br> RangeType *range = PG_GETARG_RANGE_P(1);<br>#endif<br><br>#if MOBDB_PGSQL_VERSION < 140000<br>/**<br> * Returns the union of the range values. If strict is true, it is an error<br> * that the two input ranges are not adjacent or overlapping.<br> *<br> * @note Function copied verbatim from rangetypes.c since it is static before <br> * PostgreSQL version 14.<br> */<br>static RangeType *<br>range_union_internal(TypeCacheEntry *typcache, RangeType *r1, RangeType *r2,<br> bool strict)<br>{<br> [...]<br>}<br>#endif<br><br>#if MOBDB_PGSQL_VERSION < 110000<br>PG_FUNCTION_INFO_V1(temporal_gist_decompress);<br>/**<br> * GiST decompress method for temporal values (result in a period)<o:p></o:p></p></div><div><p class=MsoNormal> *<br> * The decompress method is optional after PostgreSQL version 11<br> */<br>PGDLLEXPORT Datum<br>temporal_gist_decompress(PG_FUNCTION_ARGS)<br>{<br> GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0);<br> PG_RETURN_POINTER(entry);<br>}<br>#endif<o:p></o:p></p></div></div></div></div></div></body></html>