I would expect that JDBC would simply return a standard SQL null value.
I'm not sure whether JDBC returns an specific object representing
null, or simply a Java null - I suspect the latter.
Chris Hermansen wrote:
Martin, I like the direction you're headed in here because it seems it
can be done with the technology as-is.
Does anybody know what happens if one encounters this while processing
through e.g. JDBC? Would one expect an exception of some sort to be thrown?
Martin Davis wrote:
Sounds good to me.
If you wanted to see which geoms caused the problem, couldn't you just
run another query looking only for ones which returned NULL from the
operation, and then check the log?
The log msg could also give the first couple of points of the
offending geoms - that would narrow it down pretty good.
Does ST_Contains (and the other predicates) ever result in
TopologyExceptions? They are generally pretty darn robust, to my
knowledge. It's the overlay ops which are the real bad boys.
Paul Ramsey 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
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
