POLYGONM non-closed rings

[robe]

Is this an intentional change that we are now checking higher dimensions for closedness? In 1.5, I could do this

SELECT geom  As the_geom
FROM (VALUES ( ST_GeomFromEWKT('SRID=4326;POLYGONM((-71.1319 42.2503 1,-71.132 42.2502 3,-71.1323 42.2504 -2,-71.1322 42.2505 1,-71.1319 42.2503 0))') ),
	( ST_GeomFromEWKT('SRID=4326;POLYGONM((-71.1319 42.2512 0,-71.1318 42.2511 20,-71.1317 42.2511 -20,-71.1317 42.251 5,-71.1317 42.2509 4,-71.132 42.2511 6,-71.1319 42.2512 30))') )
		)	As g(geom);

In 2.0 it throws this error:

ERROR: geometry contains non-closed rings HINT: "…71.1322 42.2505 1,-71.1319 42.2503 0)" ←- parse error at position 115 within geometry

[mcayland]

I know when I wrote the original code, I had problems with GEOS creating invalid 2.5D polygons during testing which was why the test was changed (this should be documented in the list archives).

Now that we enforce a fairly recent version of GEOS anyhow, this problem might have gone away - I'd prefer to leave it in for the first beta, but would be prepared to allow it to match 1.5 behaviour if start to get lots of bug reports about it.

[pramsey]

Fixed at r6332