
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">The problem of how to deal with curve “decomposition” functions (ST_GeometryN, ST_Dump, ST_DumpRings) in the presence of the various Curve types, and our current inconsistent behaviour with them.<div><br></div><div><a href="https://gist.github.com/pramsey/cbf6db1edb8762854925f6b6ad6d6b35">https://gist.github.com/pramsey/cbf6db1edb8762854925f6b6ad6d6b35</a></div><div><br></div><div>What it really comes down to is “are CompoundCurve and CurvePolygon collections or not”. If “not”, if they are unitary, then there are quite a few changes to be made in the behaviour of things like ST_Dump, and other functions that currently just stuff them through collection handling. </div><div><br></div><div>So, your answer: unitary? or collection?</div></body></html>