[postgis-devel] ST_Union, ST_Collect and ST_Difference strictness

[Regina Obe]

FWIW SQL Server abides by the NULL on NULL input rule. I can't afford Oracle spatial so can't test that :)

Not that it matters, just saying :)

 

DECLARE @g geometry;  

 

SET @g = geometry::STGeomFromText('POLYGON((0 0, 0 2, 2 2, 2 0, 0 0))', 0);  

 

SELECT @g.STUnion(NULL); 

 

 

Returns  NULL

 

 

 

Though the behavior of returning the first non-null geometry for ST_Union and ST_Collect does sound appealing.

 

But then it violates my feeling it should behave like   'something' || NULL = NULL

 

But pramsey and Bjorn shot that symmetry out of the park when they changed ST_MVT.. to not return NULL for convenience.

 

My only concern with changing would be if anybody is relying on this NULL on NULL input behavior for these functions and how badly.

 

I'm fine with change in 2.5 with a big  … BREAKING change note, but not for older versions as it is a clear behavior change not resulting from fixing a real bug.

 

I'm a little less okay with it for ST_Difference

 

 

Thanks,

Regina

 

From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Darafei "Kom?pa" Praliaskouski
Sent: Tuesday, December 19, 2017 8:04 AM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: Re: [postgis-devel] ST_Union, ST_Collect and ST_Difference strictness

 

Hi,

 

Thanks for the document.

I've found just a line of RETURNS NULL ON NULL INPUT on pages 44-45.

It feels to me that this line is there as a result of copy-paste - there is no explanation in text why it matters or should be that way. 

What would be the way to get comments on this from people designing the spec?

 

It does not define ST_Collect, so this behavior can be applied to it not violating the spec.

 

пн, 18 дек. 2017 г. в 19:40, Daniel Baston <dbaston at gmail.com <mailto:dbaston at gmail.com> >:

I think strictness of these functions may be specified by OGC standards...

 

http://www.opengeospatial.org/standards/sfs

 

Dan

 

On Mon, Dec 18, 2017 at 9:03 AM, Darafei "Komяpa" Praliaskouski <me at komzpa.net <mailto:me at komzpa.net> > wrote:

Hi all,

 

I propose to change strictness for ST_Union, ST_Collect and ST_Difference to non-strict.

 

It's common in my workflows to have constructs like 

 

ST_Difference(a.geom, (select ST_Union(geom) from clipping_table b where ST_Intersects(a.geom, b.geom)))

 

Right now it has not evident side effect of geometries disappearing if ST_Union had no rows to collect. It surely can be fixed with coalesce, but you have to first know of such behavior with NULLs. :)

So, I propose non-strict handling of nulls:

ST_Union(A, NULL) => A,

ST_Union(NULL, A) => A,

ST_Union(NULL, NULL) => NULL,

ST_Collect(A, NULL) => A,

ST_Collect(NULL, A) => A,

ST_Collect(NULL, NULL) => NULL,

ST_Difference(A, NULL) = A,

ST_Difference(NULL, *) = NULL.

 

any thoughts?

 

 

_______________________________________________
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

_______________________________________________
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/20171219/107b86b8/attachment-0001.html>