Regression in ST_StartPoint()

[pramsey]

In 1.5, this SQL returns a start point:

select st_startpoint('MULTILINESTRING((0 0, 1 1))');

In 2.0 it returns NULL.

[pramsey]

Also

ST_EndPoint
ST_NumInteriorRings

Potentially others.

[robe]

I already complained about this by the way. I recall strk saying I was imagining things or it was a mistake if it ever worked when I had to rework all my tiger code to work around this issue. See ticket #1345

[strk]

It's always been like that. It's dictated by the standard. Those functions are only meant to work with LINESTRING, not MULTI*. You may argue you'd want an exception, or you'd want a guess about which geometry to consider, but it'd be a change from previous versions IIRC.

[pramsey]

It is set in the standard, but it has not "always been like that", as a quick check on an older version, or glancing at the code pre-2.0 confirms.

[robe]

So are we in agreement to simply document this as a breaking change and move on.

I think the new behavior albeit a regression, is the more correct and accepted behavior of spatial databases.

[strk]

Alright guys, sorry for the confusion. I'm fine with documenting the breaking change. Not sure if an exception would be better than a NULL but for sure it'd be another breaking change which isn't nice at this moment.

[robe]

An exception IS BETTER. It too me at least an hour to track down why my tiger geocoder was working in 1.5 and returning null points for everything in 2.0. If a simple error was thrown that said "Only works with linestraings" , that time owuld have been reduced to less than 5 minutes.

If you are going to have a breaking change, break hard not silently. The only thing worse than an error is the wrong answer you are expecting to be right.