A reasonable concern.
To which some might be tempted to reply RTFM. (I think this is the
solution offered by some proprietary vendors...)
Would having parallel sets of functions, (Paranoid/Laissez-faire) be an
option? Unpleasant to widen the API, however.
Paul Ramsey wrote:
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
--
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
