ST_CollectionExtract returns EMPTY or NULL inconsistently

[strk]

Request a POINT from a LINE and you get a NULL. Request a POINT from an EMPTY and you get an EMPTY.

Consistently returning NULL sounds like a good idea. Do you agree ?

See ​http://postgis.refractions.net/pipermail/postgis-devel/2011-February/011830.html

[mcayland]

Intuitively that sounds like a better behaviour but I'd wait for more votes on this. Note that we had this whole discussion several months ago, and hence documented the behaviour on the developer wiki here: http://trac.osgeo.org/postgis/wiki/DevWikiEmptyGeometry. I'd go through the similar cases there to get a feel for what the correct behaviour should be.

[strk]

See #457, where NULL was decided as a return for "type-misses"

[strk]

Ok, I've fixed liblwgeom to return typed EMPTIES in absence of matching types (r8717) But liblwgeom only wants COLLECTION input so can't do everything on itself.

The wrapper I then fixed to always return NULL on type miss, no matter input (be it a complex multilevel collection or a simple empty, of any type). This is r8718.

Note that I had to change an expected return in regress/regress.sql (test 159) — other existing tests were in tickets.sql and expected NULL for other kind of inputs.

At least we're consistent now: NULL return when no matches are found. It's easy for me to get back on typed empty instead, if you scream loud enough.

[strk]

Mind you: documentation needs to be updated about it. The current one says only COLLECTION input is supported and mentions EMPTY COLLECTION is returned on missing types.

[strk]

I'd be in favor of a ST_TypeExtract also using 0,1,2 for type (ala dimension)

[strk]

reopening due to requirement of documentation update

[strk]

r8720 changes back on always returning EMPTY. Seems closer to both documentation and what was requested in #457. Documentation still needs some tweaking.

[strk]

Documentation updated with r8722.