Regression: can't dump POLYGON with EMPTY shell

[strk]

This was fixed with 1.4.2 and 1.5.1, but is back in 2.0 ??

=# select postgis_lib_version();
2.0.0SVN
=# select '01030000000100000000000000'::geometry;
ERROR:  Point array has < 1 ordinates!
=# select st_astext('01030000000100000000000000'::geometry);
POLYGON(())

In 1.4.2 we get:

=# select postgis_lib_version();
1.4.2
=# select '01030000000100000000000000'::geometry;
01030000000100000000000000
=# select st_astext('01030000000100000000000000'::geometry);
POLYGON( EMPTY)

[strk]

Looks like the exception was added by pramsey with r5367 (Mar 3 2010), commit log:

    Add some documentation to the public functions.

Paul: was it intentional to commit functional change ? the commit log suggests it wasn't… And now I wonder if the same problem affects 1.5

[strk]

note that it's really the output (dump) functions complaining, as the parser understands that very well. It's a polygon with a zero-points shell. This is different from 'POLYGON EMPTY', which is really encoded as a polygon with NO rings.

[strk]

Other intersting results:

strk=# select st_isempty('01030000000100000000000000'::geometry);
 st_isempty
------------
 f
(1 row)

strk=# select st_isvalid('01030000000100000000000000'::geometry);
 st_isvalid 
------------
 t
(1 row)

[strk]

Fixed (and regress-tested) by r7102

[pramsey]

Rather than adding another semantic for EMPTY WKB polygons, can we morph this case into the "standard" WKB representation for that case, namely, a polygon with a ring count of zero and nothing else? (Would do this by having this case return "true" in the lwgeom_is_empty() function). Incidentally, does the wkb_in code handle the one-empty-ring case correctly (construct an empty polygon?)

[strk]

Morph how ? Automatically on parsing ? Explicitly on request ? Note that the bug is about _dumping_, not parsing. You want to dump something different than you read ?

coliver had an ST_Homogenize code laying around somewhere, such morph could be undertaken by that.