http://www.postgresql.org/docs/current/static/functions-geometry.html
I wish it explained what arguments each of the operators accepts, and
whether any automatic conversions take place (like polygon to box in
that 8.3 issue).
What happens when I call ?# or ?- on a polygon and point? Two points? Open =
path?
Some of these are obvious, but others not so much.
2011/3/8 Robert Haas <robertmhaas@gmail.com>:
> On Wed, Feb 16, 2011 at 10:33 AM, Konrad Garus <konrad.garus@gmail.com> w=
rote:
>> 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 inter=
sect:
>>>
>>>> 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" operat=
ions 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 d=
oes a
>>> =A0 =A0 =A0 =A0more correct check. The polygon @> and <@ (contains/cont=
ained
>>> =A0 =A0 =A0 =A0by) operators formerly checked to see if one polygon's v=
ertexes
>>> =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 li=
ne
>>> =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. =A0Aren't they?
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
--=20
Konrad Garus
