[postgis-devel] Promote Geometry to MultiGeometry on Insert

[Paul Ramsey]

> On 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.

Hard to predict.
Even in our own remit, making sure that every function that takes a Multi* can ingest a singleton and vice versa would be a bit of a large project.

P

>  
> 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