#5306 closed enhancement (fixed)
Function to display to user what versions of libs PostGIS was compiled against
Reported by: | robe | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 3.4.0 |
Component: | postgis | Version: | master |
Keywords: | Cc: |
Description
For primarily GEOS and sometimes PROJ, the features we enable are dependent on what version of these dependencies PostGIS is compiled against.
Many users get their PostGIS and PostgreSQL from pgdg (apt.postgresql.org) , (yum.postgresql.org). They may on occasion, supplement these by compiling their own GEOS or getting it from a GIS dedicated repo (e.g. ubuntu-gis).
As far as PGDG is concerned, this is generally not an issue for yum.postgresql.org since that ships it's own GEOS/GDAL/PROJ. For apt.postgresql.org, their compiles are against upstream debian/ubuntu shipped packages. This means even if you have the newest PostGIS you might end up with a GEOS 3.10 on a Jammy, and a GEOS 3.9 on a Focal. Then if you use ubuntugis, your PostGIS was compiled against a GEOS 3.10 but running with a GEOS 3.11.
When someone does
SELECT postgis_full_version();
They are informed of the runtime library, which is important, to know patch level fixes and many performance enhancements, but is misleading when it comes to new features.
You might be running with a GEOS 3.11, but if your postgis is compiled with GEOS 3.10, then those new features exposed for GEOS 3.11, are not available to you.
So solution, at least for GEOS
I think
SELECT postgis_full_version();
should state both the runtime and the compiled version in cases where they are different. For cases where they are the same (which is probably most), we can keep the message same as before.
For Proj since we have removed support for Proj < 6.2 in PostGIS and most of the issues we've had are around PROJ 4 - 7 probably not too important to state that, though may be in the future
In fce2bbce/git: