Opened 8 months ago
Last modified 8 months ago
#5624 new defect
Provide more info about out of date geos when checking PostGIS_Full_Version() ;
| Reported by: | Lars Aksel Opsahl | Owned by: | strk |
|---|---|---|---|
| Priority: | medium | Milestone: | PostGIS 3.5.0 |
| Component: | upgrade | Version: | 3.4.x |
| Keywords: | Cc: | Lars Aksel Opsahl |
Description (last modified by )
Case 1 (using a EOL geos)
POSTGIS="3.4.0 0874ea3" [EXTENSION] PGSQL="120" GEOS="3.10.1-CAPI-1.16.0" SFCGAL="1.3.7" PROJ="8.2.0 NETWORK_ENABLED=OFF URL_ENDPOINT=https://cdn.proj.org USER_WRITABLE_DIRECTORY=/tmp/proj DATABASE_PATH=/usr/share/proj/proj.db" LIBXML="2.9.10" LIBJSON="0.13.1" LIBPROTOBUF="1.3.3" WAGYU="0.5.0 (Internal)" TOPOLOGY
Then a message like this could be added
Your geos has reached EOL, please try to upgrade your geos. To be sure to get all feature supported latest geos at [https://libgeos.org/usage/download/]
Case 2 (Using a valid geos, but not latest)
POSTGIS="3.4.0 0874ea3" [EXTENSION] PGSQL="120" GEOS="3.10.6" SFCGAL="1.3.7" PROJ="8.2.0 NETWORK_ENABLED=OFF URL_ENDPOINT=https://cdn.proj.org USER_WRITABLE_DIRECTORY=/tmp/proj DATABASE_PATH=/usr/share/proj/proj.db" LIBXML="2.9.10" LIBJSON="0.13.1" LIBPROTOBUF="1.3.3" WAGYU="0.5.0 (Internal)" TOPOLOGY
Then a message like this could be added
Your geos is valid, but to be sure to get all feature supported try to use latest geos at [https://libgeos.org/usage/download/]
Case 3 (Using a latest geos or newer)
POSTGIS="3.4.0 0874ea3" [EXTENSION] PGSQL="120" GEOS="3.12.1" SFCGAL="1.3.7" PROJ="8.2.0 NETWORK_ENABLED=OFF URL_ENDPOINT=https://cdn.proj.org USER_WRITABLE_DIRECTORY=/tmp/proj DATABASE_PATH=/usr/share/proj/proj.db" LIBXML="2.9.10" LIBJSON="0.13.1" LIBPROTOBUF="1.3.3" WAGYU="0.5.0 (Internal)" TOPOLOGY
There is no printed message about geos
Change History (7)
comment:1 by , 8 months ago
| Description: | modified (diff) |
|---|
comment:2 by , 8 months ago
| Component: | postgis → upgrade |
|---|---|
| Milestone: | PostGIS 3.4.2 → PostGIS 3.5.0 |
| Owner: | changed from to |
Pushing this to 3.5.0 since we can't be changing the output at micro versions since some people parse that info. I'm still against this idea BTW, but I'll leave it up to strk to decide what to do.
follow-up: 5 comment:3 by , 8 months ago
I don't think we should do online lookups to tell what's EOL and what not, but we could leave a note about PostGIS having been compiled to a version of GEOS which is not the one recommended at the time of PostGIS release. Would that help ?
follow-up: 6 comment:4 by , 8 months ago
Note that if the version of GEOS used when compiling does not match the version of GEOS found at runtime should already be giving you the compiled version in parens, right after the runtime version.
I'm thinking we should really have a JSON flavor of this version function as it would be much easier to parse.
Feel free to file a ticket on the GEOS side to expose an web endpoint to report what the latest version is, btw, as that endpoint would be needed shall you decide to implement the check you are asking for in your custom code.
comment:5 by , 8 months ago
Replying to strk:
I don't think we should do online lookups to tell what's EOL and what not, but we could leave a note about PostGIS having been compiled to a version of GEOS which is not the one recommended at the time of PostGIS release. Would that help ?
Yes I think that is very nice. I believe then we may avoid to report "invalid" tickets because of EOL geos after an upgrade to latest postgis.
follow-up: 7 comment:6 by , 8 months ago
Replying to strk:
Note that if the version of GEOS used when compiling does not match the version of GEOS found at runtime should already be giving you the compiled version in parens, right after the runtime version.
I'm thinking we should really have a JSON flavor of this version function as it would be much easier to parse.
Yes agree and then it's much more safe to add new elements without cause parsing problem for existing users.
comment:7 by , 8 months ago
Replying to Lars Aksel Opsahl:
Replying to strk:
Note that if the version of GEOS used when compiling does not match the version of GEOS found at runtime should already be giving you the compiled version in parens, right after the runtime version.
I'm thinking we should really have a JSON flavor of this version function as it would be much easier to parse.
Yes agree and then it's much more safe to add new elements without cause parsing problem for existing users.
I agree too then we can stuff as much as we want in there as long as old queries for specific items don't break.
A assume doing online check here maybe out off scope ? So if you install postgis and never touch server the next 5 years there may not be passed out any info about EOL geos.
I thinks what's more important is that when you install a new postgis and you think that you have an update to date system, it would be nice with a warning message about geos if that is not fully up to date.