[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgis-devel
Subject:    Re: [postgis-devel] Promote Geometry to MultiGeometry on Insert
From:       Paul Ramsey <pramsey () cleverelephant ! ca>
Date:       2023-02-23 21:03:24
Message-ID: CACowWR3cxhcbV9a7QEgvizJm4qQW8K+o7343jT-+9QQo0Eq6HQ () mail ! gmail ! com
[Download RAW message or body]

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@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@lists.osgeo.org] On Behalf Of \
>                 Martin Davis
> Sent: Friday, February 17, 2023 3:25 PM
> To: PostGIS Development Discussion <postgis-devel@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@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@lists.osgeo.org] On Behalf Of \
>                 Martin Davis
> Sent: Friday, February 17, 2023 12:49 PM
> To: PostGIS Development Discussion <postgis-devel@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@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@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
_______________________________________________
postgis-devel mailing list
postgis-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/postgis-devel


[prev in list] [next in list] [prev in thread] [next in thread]