ST_Polygonize doesn't accept NULL geometries

[kohnivo]

Postgis 2.2.1 running on Win (PG 9.4.5 64bit, spec with postgis_full_version():

"POSTGIS="2.2.1 r14555" GEOS="3.5.0-CAPI-1.9.0 r4090" SFCGAL="1.2.2" PROJ="Rel. 4.9.1, 04 March 2015" GDAL="GDAL 2.0.1, released 2015/09/15" LIBXML="2.7.8" LIBJSON="0.12" TOPOLOGY RASTER"

) throws an error if trying to do ST_Polygonize on NULL geometries:

ERROR: getPoint4d_p: point offset out of range
SQL state: XX000

Test code (either linestring or multilinestring):

WITH w AS (SELECT NULL::geometry(MULTILINESTRING,5514) as geom)
SELECT ST_Polygonize(geom)
FROM w

Postgis 2.1.1 running on Win (PG 9.3 64bit) and Ubuntu (PG 9.4 64bit) throws this:

ERROR: Exception in LWGEOM2GEOS: curved geometry not supported.
SQL state: XX000

Maybe it is not a bug but it confused me quite a lot and took me some time to find out what is going on, because I didn't know that there are some NULLs in the dataset. For some reason I would expect returned NULL same as eg. ST_Envelope or ST_BuildArea does.

[dbaston]

I've fixed this in trunk at r14882.

Should this be backported to 2.2? It does change behavior, but it looks like the old behavior involves a dirty read, based on the error messages kohnivo is reporting, as well as what I'm seeing:

postgres=# SELECT '#3470', ST_Polygonize(ARRAY[NULL::geometry]::geometry[]);
ERROR:  Unknown geometry type: 64 - Invalid type
postgres=# SELECT '#3470', ST_Polygonize(ARRAY['LINESTRING (0 0, 1 1)', NULL::geometry]::geometry[]);
ERROR:  Unknown geometry type: 17337632 - Invalid type
postgres=# SELECT '#3470', ST_Polygonize(ARRAY['LINESTRING (0 0, 1 1)', NULL]::geometry[]);
ERROR:  Unknown geometry type: 0 - Unknown

Porting it back to 2.1 is trickier, as the fix involves switching to simplified code introduced in 2.2.

[strk]

For sure a dirty read fix needs backporting. But before backporting, should we also have a test with an array containing both null and not-null geometries ? Ideally we'd have the same behavior as ST_Collect (to be checked). There are two possible handling: the null elements are just skipped OR the whole array is considered null (and thus the output is also null)

[dbaston]

NULL elements are just skipped, in ST_Collect, ST_Union, and now ST_Polygonize. I can add a test to show this for ST_Polygonize.

[dbaston]

Added additional test and backported to 2.2. May look at 2.1 later.

[robe]

I personally wouldn't bother with 2.1 especially if it changes behavior in any way.

I think we should just close this ticket and call it a day.

[dbaston]

Calling it a day, then.