[postgis-users] Topological Exceptions

[Paul Ramsey]

Since the current behavior results in queries which just don't run to
completion, I don't think that making the null behavior the default
would cause any harm. I am concerned that people notice that their
queries are in fact skipping some of the geometry pairs due to the
exception swallowing.

P

On 3/12/08, Kevin Neufeld <kneufeld at refractions.net> wrote:
> Martin Davis wrote:
>  > 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.
>  >
>
> We could override the methods to take an addition parameter,
>  'ignore_exceptions boolean'.
>
>  In which case, we would have:
>  ST_Contains(geom,geom,boolean) => true, false, or null (if set to true)
>  ST_Contains(geom,geom)
>   a simple wrapper for ST_Contains(geom,geom,false)
>
>  This way, people's queries won't break or wonder why the change in their
>  outcomes.  If they want the "null" behaviour, they can ask for it.
>
>
>  -- Kevin
>
> >> On 3/12/08, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
>
> >>> ...
>
> >>>
>  >>>  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
>  postgis-users at postgis.refractions.net
>  http://postgis.refractions.net/mailman/listinfo/postgis-users
>