[postgis-devel] Promote Geometry to MultiGeometry on Insert

[Regina Obe]

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 <mailto: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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20230217/36e595e3/attachment.htm>