[postgis-devel] Promote Geometry to MultiGeometry on Insert

[Martin Davis]

Could mixed atomic/multi be supported with a different typmod code?  Then
its net new and no breaking change.

On Fri, Feb 17, 2023 at 11:28 AM Regina Obe <lr at pcorp.us> wrote:

> Would that be a breaking change for any down the stream apps.  Suddenly
> mixing multi with singles?
>
> That would be my main concern.
>
>
>
> If there is no performance benefit to allowing columns to mix multi and
> singles, I’d rather not as it sounds it would be both a hassle and could
> cause damage downstream.
>
>
>
> *From:* postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] *On
> Behalf Of *Martin Davis
> *Sent:* Friday, February 17, 2023 12:49 PM
> *To:* PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
> *Subject:* Re: [postgis-devel] Promote Geometry to MultiGeometry on Insert
>
>
>
> I agree with this.  It seems better to provide more appropriate
> constraints than to modify data.
>
>
>
> Like it or now, we're stuck with the OGC model for the foreseeable
> future.  But the pain points can be reduced by removing unwanted
> distinctions between atomic and Multi-geometries wherever possible.
>
>
>
> On Thu, Feb 16, 2023 at 8:43 PM Darafei "Komяpa" Praliaskouski <
> me at komzpa.net> wrote:
>
> I believe that multigeometry constraint is instead a not well-thought
> constraint inherited from very legacy systems.
>
>
> The useful ones are "is it point/multipoint", "is it line/multiline", "is
> it area/multiarea". With check for the multi- being with options "no" and
> "could be multi, could be single". I don't like us pushing people to
> convert all singles to multi: this may mean that in some time we will not
> have tables with plain polygons anymore.
>
>
>
> I'd say that if we implement such a change we also need to have a nice way
> to have "linear" or "areal" dimensionality constraint on the data that will
> check that data is poly/multipoly or line/multiline, so it could be
> recommended as replacement, with simple results being in the table, not
> forcing everything to be more complex.
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20230217/575b8cc1/attachment.htm>