[postgis-devel] Bugs in gserialized_gist_compress_2d

Paul Ramsey pramsey at cleverelephant.ca
Wed Sep 25 16:00:03 PDT 2013


OK, I've ticketed it, for what that's worth. I do believe it's an important correctness issue. 

http://trac.osgeo.org/postgis/ticket/2487 

Since I have you here... any guesses on this?

http://obartunov.livejournal.com/174411.html

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


On Friday, September 20, 2013 at 3:42 AM, Alexander Korotkov wrote:

> On Sun, Sep 15, 2013 at 1:26 AM, Paul Ramsey <pramsey at cleverelephant.ca (mailto:pramsey at cleverelephant.ca)> wrote:
> > We talked about invalid keys, and we're going to need some. I'm going to have to backtrack and remember where/when we did this last time. Basically any instance of GEOMETRY EMPTY, or a geometry with NaN coordinates, or Inf coordinates, should generate an invalid key (is there any way to just leave it out of the index, since that's effectively what we want anyways...)
> 
> 
> General idea is that index scan must give same results as sequential scan.
> 
> Generally there are 3 cases: inf coordinates, nan coordinates, lower bound greater than upper bound. 
> Let's consider them:
> 1) inf coordinates
> I don't understand why you're so against inf coordinates. For example, box with infinite upper bound is legal geometrical object. Probably, there are some use cases where infinite bounds are useful. However, if you would like to prohibit results of index scans with infinite bounds, you should corrects operators itself first. Otherwise, it would be inconsistent behaviour. The only index operator is &&&. So it wouldn't be hard to make index scans and sequential scans consistent themselves. 
> 2) NaN coordinates
> Any single NaN coordinate makes &&& operator always return false. So, in this case you can do whatever: leave box3df as is or replace it with all NaNs.
> 3) lower bound is greater than upper bound
> I wonder how it could be possible. Bug in lwgeom? If it could be caused only by bug then I think trigger an error is proper solution for this case. 
> 
> ------
> With best regards,
> Alexander Korotkov. 
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org (mailto:postgis-devel at lists.osgeo.org)
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel






More information about the postgis-devel mailing list