Before getting too enthused about this, the net effect will be to convert a whole bunch of questions about "why is my query failing" to "why is my query returning incomplete answers"...
We can still spit out NOTICEs, but will people put 2 + 2 together and recognize that their return sets are partials because of the topology failures? P On 3/12/08, Paul Ramsey <[EMAIL PROTECTED]> wrote: > On 3/12/08, Martin Davis <[EMAIL PROTECTED]> wrote: > > > Orginally the idea was that it was nice to report the actual nature of > > the exception, since it contains an indication of where the error > > occurred. It would be nice to be able to continue to have access to > > this information. One way to do this would be to have a parallel set of > > functions which would abort as they do now. Or is there some other way > > to report this info - to a log somewhere perhaps? > > > I prefer using something like NULL to trying to create a new geometry > type to encompass the error... particularly if the error conditions > aren't that interesting to people. We can get into the log easily > enough by using a WARNING log level, the only question then is how to > identify which geometries caused the failure. One way might be to > hash the geometries, so that if people want to find their bad > geometries from the log they can just select for the hash value. > > This means that the return values of > > ST_Contains(geom,geom) => true, false or null > > and > > ST_Intersection(geom,geom) => geometry or null > > I just checked, and null seems to be interpreted as false in a WHERE > clause, so adding this behavior probably wouldn't wreck too many > joins. > > > Paul > _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
