[PostGIS] #5920: Different data insertion orders may cause inconsistent ST_Polygonize results

[PostGIS]

#5920: Different data insertion orders may cause inconsistent ST_Polygonize
results
---------------------------+---------------------------
 Reporter:  dmyzl          |      Owner:  pramsey
     Type:  defect         |     Status:  new
 Priority:  medium         |  Milestone:  PostGIS 3.5.4
Component:  postgis        |    Version:  3.5.x
 Keywords:  ST_Polygonize  |
---------------------------+---------------------------
 The following two SQL statements differ only in the data insertion order,
 but they produce different results from the `ST_Polygonize` function.

 {{{
 DROP TABLE IF EXISTS polyedges;
 CREATE TABLE polyedges(id INT,geom Geometry);
 INSERT INTO polyedges VALUES
 (1, ST_GeomFromText('LINESTRING(0 0,1 0)')),
 (2, ST_GeomFromText('LINESTRING(0
 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999,0
 0)')),
 (3, ST_GeomFromText('LINESTRING(1 0,1 1)')),
 (4, ST_GeomFromText('LINESTRING(1 1,0
 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999)'));
 COMMIT;
 SELECT ST_Polygonize(geom) FROM polyedges;
 -- return: null

 DROP TABLE IF EXISTS polyedges;
 CREATE TABLE polyedges(id INT,geom Geometry);
 INSERT INTO polyedges VALUES
 (1, ST_GeomFromText('LINESTRING(0
 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999,0
 0)')),
 (2, ST_GeomFromText('LINESTRING(0 0,1 0)')),
 (3, ST_GeomFromText('LINESTRING(1 0,1 1)')),
 (4, ST_GeomFromText('LINESTRING(1 1,0
 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999)'));
 COMMIT;
 SELECT ST_Polygonize(geom) FROM polyedges;
 -- return: 010700000000000000
 }}}

 While the second SQL statement returns a non-NULL result, the output is
 actually incorrect. As shown in the SQL statements, there's a point with
 an extremely large Y-coordinate (309 nines). When we reduce this
 Y-coordinate value by one digit (to 308 nines), both SQL statements
 produce identical results.

 postgis_full_version:

 {{{
 POSTGIS="3.5.3 0" [EXTENSION] PGSQL="170" GEOS="3.13.1-CAPI-1.19.2"
 SFCGAL="SFCGAL 1.5.0, CGAL 5.6, BOOST 1.74.0" PROJ="9.3.1
 NETWORK_ENABLED=OFF URL_ENDPOINT=https://cdn.proj.org
 USER_WRITABLE_DIRECTORY=/home/yzl/.local/share/proj
 DATABASE_PATH=/home/yzl/project/build_pg_postgis/proj-9.3.1/tmp_install/share/proj/proj.db"
 (compiled against PROJ 9.3.1) GDAL="GDAL 3.7.2, released 2023/09/05"
 LIBXML="2.9.13" LIBJSON="0.17" LIBPROTOBUF="1.3.3" WAGYU="0.5.0
 (Internal)" (core procs from "3.5.2 dea6d0a" need upgrade) TOPOLOGY
 (topology procs from "3.5.2 dea6d0a" need upgrade) RASTER (raster procs
 from "3.5.2 dea6d0a" need upgrade) (sfcgal procs from "3.5.2 dea6d0a" need
 upgrade)
 }}}
-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/5920>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.