[postgis-devel] ST_LineLocatePoint with empty geom raise error

[Paul Ramsey]

Right, but empty != null, and doesn’t obey null semantics.
Basic example,

ST_Union(polygon,empty) = polygon

Semantically, empty is closer to zero than to null.
Anyways, in this *particular* example, I’m not sure that null is better than error. In either case a condition probably has to be trapped, either the incoming empty to stop and error, or the outgoing null, to stop a null propagation.

P.

-- 
Paul Ramsey
http://cleverelephant.ca
http://postgis.net

On July 11, 2014 at 1:11:40 AM, Rémi Cura (remi.cura at gmail.com) wrote:

Not willing to put a fight,
but I think the standard behaviour for logic of (TRUE,FALSE,NULL) in postgres is whatever involves NULL is NULL.
By extending this concept to null geom, one should expect a null output.
And i don't feel it should be this function that forces you to take special care of empty geometry.
If you are worried about empty geometry for your special case, you can still filter it befor or after (with a where result is not null on result ! )

That being said, I don't see major interest in empty geom instead of null ..
Cheers,
Rémi-C
 
Cheers,
Rémi-C


2014-07-10 23:31 GMT+02:00 Sandro Santilli <strk at keybit.net>:
On Thu, Jul 10, 2014 at 01:45:49PM -0400, Paragon Corporation wrote:
> or Empty happy. It should be a POINT EMPTY of course :)

ST_LineLocatePoint retuns a floating point number between 0 and 1.

--strk;
_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel

_______________________________________________  
postgis-devel mailing list  
postgis-devel at lists.osgeo.org  
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20140711/99b1a31e/attachment.html>