[postgis-devel] Promote Geometry to MultiGeometry on Insert

[Paul Ramsey]

If anyone wants to try it out, it's available at

https://github.com/postgis/postgis/pull/720


On Fri, Feb 17, 2023 at 1:57 PM Regina Obe <lr at pcorp.us> wrote:
>
> 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> 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
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel