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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > [email protected] > http://postgis.refractions.net/mailman/listinfo/postgis-users > _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
