[postgis-devel] Promote Geometry to MultiGeometry on Insert

[Regina Obe]

But then all those tools would have to account for a new typmod type otherwise why bother using the new typmod.

 

If it’s not going to be a big performance gain, I question the benefit of so much change.

 

The only time this strict behavior annoys me is when I’m inserting into a table.

 

From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Martin Davis
Sent: Friday, February 17, 2023 3:25 PM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: Re: [postgis-devel] Promote Geometry to MultiGeometry on Insert

 

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

_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org <mailto: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/504afc1c/attachment-0001.htm>