I can be so tiresome sometimes! What I meant to ask was, when bad geometry is encountered and some predicates are tempted to give up, what happens in the JDBC context - is an exception thrown. Clearly if you move over to the returning nulls then a Java null is the reasonable behaviour.
Sorry to be so unclear! Martin Davis wrote: > 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 >>>> >>>> >> >> >> > -- Regards, Chris Hermansen · mailto:[EMAIL PROTECTED] tel:+1.604.714.2878 · fax:+1.604.733.0631 Timberline Natural Resource Group · http://www.timberline.ca 401 · 958 West 8th Avenue · Vancouver BC · Canada · V5Z 1E5 C'est ma façon de parler. _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
