Re: BUG #5889: "Intersects" for polygons broken

On Wed, Feb 16, 2011 at 10:33 AM, Konrad Garus <konrad.garus@gmail.com> wro=
te:
> 2011/2/16 Tom Lane <tgl@sss.pgh.pa.us>:
>> "Konrad Garus" <konrad.garus@gmail.com> writes:
>>> && operator seems to be broken for polygons whose bounding boxes inters=
ect:
>>
>>> select polygon'((0,0), (1,2), (0,2))' && polygon'((0.5, 0), (1,0), (1,1=
))';
>>> =A0?column?
>>> ----------
>>> =A0t
>>> (1 row)
>>
>> This is fixed as of 9.0; see the release notes at
>> http://www.postgresql.org/docs/9.0/static/release-9-0.html
>> which say
>>
>> =A0 =A0 =A0 =A0Correct calculations of "overlaps" and "contains" operati=
ons for polygons (Teodor Sigaev)
>>
>> =A0 =A0 =A0 =A0The polygon && (overlaps) operator formerly just checked =
to see
>> =A0 =A0 =A0 =A0if the two polygons' bounding boxes overlapped. It now do=
es a
>> =A0 =A0 =A0 =A0more correct check. The polygon @> and <@ (contains/conta=
ined
>> =A0 =A0 =A0 =A0by) operators formerly checked to see if one polygon's ve=
rtexes
>> =A0 =A0 =A0 =A0were all contained in the other; this can wrongly report =
"true"
>> =A0 =A0 =A0 =A0for some non-convex polygons. Now they check that all line
>> =A0 =A0 =A0 =A0segments of one polygon are contained in the other.
>
> Thank you. How about the point of more informative docs that would
> explain supported types, automatic conversions and all such caveats
> (also for 8.3 and 8.4)?

I think a lot of these things are already documented.  Aren't they?

--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company