Re: No ~ operator for box, point

From: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: No ~ operator for box, point
Date: 2007-02-27 23:52:38
Message-ID: 20070227235237.GO51916@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 20, 2007 at 04:22:27PM -0500, Bruce Momjian wrote:
> Added to TODO:
>
> * Add missing operators for geometric data types
>
> Some geometric types do not have the full suite of geometric operators,
> e.g. box @> point
>

I've started looking at this, and ISTM that at least part of this could
be solved by allowing some implicit casts. Given that the geometry data
types are point, line, lseg, box, path, polygon, circle, I think the
following should be safe:

box -> polygon
lseg -> open path
polygon -> closed path

I would argue that this is similar to int2 -> int4 -> int8: a box is a
type of polygon, a polygon is a closed path (that doesn't intersect,
which needs to be added to the docs, btw), and a line segment is an open
path.

Is there any reason not to make these casts implicit? If there is,
what's the best way to go about adding operators for cases where
equivalent operators exist? (IE: @>(box,point) doesn't exist, but
@>(polygon,point) does, and should suffice for @>(box,point) with
appropriate casting)

Actually, looking at one example (@(point,box) vs @(point,poly)), part
of the reason is that it's far simpler to deal with a box than a generic
polygon.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2007-02-27 23:59:41 Re: COMMIT NOWAIT Performance Option
Previous Message Bruce Momjian 2007-02-27 23:51:20 Re: [HACKERS]