[postgis-users] Topological Exceptions

[Paul Ramsey]

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 <pramsey at cleverelephant.ca> wrote:
> On 3/12/08, Martin Davis <mbdavis at refractions.net> 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
>