<div dir="ltr">iI we do this can we also make sure functions accept both Geom and MultiGeom where that makes sense?  That will lessen the pain of transition, and also make queries simpler.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 16, 2023 at 9:20 AM Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In 3.1 we started allowing people to insert SRID=0 geometries into columns with an SRID typmod, so that people wouldn't have to always add the SRID value when what they *meant* was to insert a conforming geometry into the column. SRID conflicts would still raise an error, but a SRID=0 is not a conflicting SRID, it's an unset SRID, so accepting the geometry and adding the typmod column made sense.<br>
<br>
In a similar vein, it kind of makes sense to accept simple geometries as input to multigeometry columns:<br>
<br>
CREATE TABLE mp (geom Geometry(MultiPolygon, 3005);<br>
INSERT INTO mp VALUES ('POLYGON(...)');<br>
SELECT ST_AsEWKT(geom) FROM mp;<br>
<br>
SRID=3005;MULTIPOLYGON(...)<br>
<br>
Again, in the spirit of "do what I mean". If 100% of the time, the response to a "geometry type mismatch" is just to wrap the input in ST_Multi(), the "data integrity check" isn't really helping, it's just adding a step to every interaction.<br>
<br>
Comments and concerns?<br>
<br>
P<br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
</blockquote></div>