Thread: No ~ operator for box, point
decibel=# select version();PostgreSQL 8.3devel on i386-apple-darwin8.8.2, compiled by GCC i686-apple-darwin8-gcc-4.0.1 (GCC)4.0.1 (Apple Computer, Inc. build 5363) decibel=# select box '((0,0),(2,2))' ~ point '(1,1)'; ERROR: operator does not exist: box ~ point LINE 1: select box '((0,0),(2,2))' ~ point '(1,1)'; Any reason this doesn't exist? -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
On 1/25/07, Jim C. Nasby <jim@nasby.net> wrote: > decibel=# select version(); > PostgreSQL 8.3devel on i386-apple-darwin8.8.2, compiled by GCC i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer,Inc. build 5363) > > decibel=# select box '((0,0),(2,2))' ~ point '(1,1)'; > ERROR: operator does not exist: box ~ point > LINE 1: select box '((0,0),(2,2))' ~ point '(1,1)'; I don't see a reason, although you can do it with polygon and not box.Also, I can't find the ~ operator defined for polygonin the documentation, am I missing something? merlin
On Thu, Jan 25, 2007 at 01:59:33PM -0500, Merlin Moncure wrote: > On 1/25/07, Jim C. Nasby <jim@nasby.net> wrote: > >decibel=# select version(); > > PostgreSQL 8.3devel on i386-apple-darwin8.8.2, compiled by GCC > > i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5363) > > > >decibel=# select box '((0,0),(2,2))' ~ point '(1,1)'; > >ERROR: operator does not exist: box ~ point > >LINE 1: select box '((0,0),(2,2))' ~ point '(1,1)'; > > I don't see a reason, although you can do it with polygon and not box. > Also, I can't find the ~ operator defined for polygon in the > documentation, am I missing something? I ran into this the other day too. But box ~ box does exist, which worked for my purposes, but it did surprise me. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Martijn van Oosterhout <kleptog@svana.org> writes:
> On Thu, Jan 25, 2007 at 01:59:33PM -0500, Merlin Moncure wrote:
>> On 1/25/07, Jim C. Nasby <jim@nasby.net> wrote:
>>> decibel=# select box '((0,0),(2,2))' ~ point '(1,1)';
>>> ERROR: operator does not exist: box ~ point
>>
>> I don't see a reason, although you can do it with polygon and not box.
Seems like an old oversight.
>> Also, I can't find the ~ operator defined for polygon in the
>> documentation, am I missing something?
~ is deprecated, "contains" is preferentially spelled @> now.
regards, tom lane
On Jan 25, 2007, at 6:26 PM, Tom Lane wrote: > Martijn van Oosterhout <kleptog@svana.org> writes: >> On Thu, Jan 25, 2007 at 01:59:33PM -0500, Merlin Moncure wrote: >>> On 1/25/07, Jim C. Nasby <jim@nasby.net> wrote: >>>> decibel=# select box '((0,0),(2,2))' ~ point '(1,1)'; >>>> ERROR: operator does not exist: box ~ point >>> >>> I don't see a reason, although you can do it with polygon and not >>> box. > > Seems like an old oversight. Ok. If I ever get some time I'll submit a patch to bring everything in-line (there's other missing operators as well). >>> Also, I can't find the ~ operator defined for polygon in the >>> documentation, am I missing something? > > ~ is deprecated, "contains" is preferentially spelled @> now. Ok, I'll keep that in mind. -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Can I get a TODO on this? --------------------------------------------------------------------------- Jim Nasby wrote: > On Jan 25, 2007, at 6:26 PM, Tom Lane wrote: > > Martijn van Oosterhout <kleptog@svana.org> writes: > >> On Thu, Jan 25, 2007 at 01:59:33PM -0500, Merlin Moncure wrote: > >>> On 1/25/07, Jim C. Nasby <jim@nasby.net> wrote: > >>>> decibel=# select box '((0,0),(2,2))' ~ point '(1,1)'; > >>>> ERROR: operator does not exist: box ~ point > >>> > >>> I don't see a reason, although you can do it with polygon and not > >>> box. > > > > Seems like an old oversight. > > Ok. If I ever get some time I'll submit a patch to bring everything > in-line (there's other missing operators as well). > > >>> Also, I can't find the ~ operator defined for polygon in the > >>> documentation, am I missing something? > > > > ~ is deprecated, "contains" is preferentially spelled @> now. > > Ok, I'll keep that in mind. > -- > Jim Nasby jim@nasby.net > EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) > > > > ---------------------------(end of broadcast)--------------------------- > TIP 7: You can help support the PostgreSQL project by donating at > > http://www.postgresql.org/about/donate -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
* Add missing operators for geometric data types and operators
There are geometric data types that do not have the full suite
of geometric operators defined; for example, box @> point does not exist.
On Jan 26, 2007, at 9:32 PM, Bruce Momjian wrote:
>
> Can I get a TODO on this?
>
> ----------------------------------------------------------------------
> -----
>
> Jim Nasby wrote:
>> On Jan 25, 2007, at 6:26 PM, Tom Lane wrote:
>>> Martijn van Oosterhout <kleptog@svana.org> writes:
>>>> On Thu, Jan 25, 2007 at 01:59:33PM -0500, Merlin Moncure wrote:
>>>>> On 1/25/07, Jim C. Nasby <jim@nasby.net> wrote:
>>>>>> decibel=# select box '((0,0),(2,2))' ~ point '(1,1)';
>>>>>> ERROR: operator does not exist: box ~ point
>>>>>
>>>>> I don't see a reason, although you can do it with polygon and not
>>>>> box.
>>>
>>> Seems like an old oversight.
>>
>> Ok. If I ever get some time I'll submit a patch to bring everything
>> in-line (there's other missing operators as well).
>>
>>>>> Also, I can't find the ~ operator defined for polygon in the
>>>>> documentation, am I missing something?
>>>
>>> ~ is deprecated, "contains" is preferentially spelled @> now.
>>
>> Ok, I'll keep that in mind.
>> --
>> Jim Nasby jim@nasby.net
>> EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
>>
>>
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 7: You can help support the PostgreSQL project by donating at
>>
>> http://www.postgresql.org/about/donate
>
> --
> Bruce Momjian bruce@momjian.us
> EnterpriseDB http://www.enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
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 --------------------------------------------------------------------------- Jim Nasby wrote: > * Add missing operators for geometric data types and operators > > There are geometric data types that do not have the full suite > of geometric operators > defined; for example, box @> point does not exist. > > On Jan 26, 2007, at 9:32 PM, Bruce Momjian wrote: > > > > > Can I get a TODO on this? > > > > ---------------------------------------------------------------------- > > ----- > > > > Jim Nasby wrote: > >> On Jan 25, 2007, at 6:26 PM, Tom Lane wrote: > >>> Martijn van Oosterhout <kleptog@svana.org> writes: > >>>> On Thu, Jan 25, 2007 at 01:59:33PM -0500, Merlin Moncure wrote: > >>>>> On 1/25/07, Jim C. Nasby <jim@nasby.net> wrote: > >>>>>> decibel=# select box '((0,0),(2,2))' ~ point '(1,1)'; > >>>>>> ERROR: operator does not exist: box ~ point > >>>>> > >>>>> I don't see a reason, although you can do it with polygon and not > >>>>> box. > >>> > >>> Seems like an old oversight. > >> > >> Ok. If I ever get some time I'll submit a patch to bring everything > >> in-line (there's other missing operators as well). > >> > >>>>> Also, I can't find the ~ operator defined for polygon in the > >>>>> documentation, am I missing something? > >>> > >>> ~ is deprecated, "contains" is preferentially spelled @> now. > >> > >> Ok, I'll keep that in mind. > >> -- > >> Jim Nasby jim@nasby.net > >> EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) > >> > >> > >> > >> ---------------------------(end of > >> broadcast)--------------------------- > >> TIP 7: You can help support the PostgreSQL project by donating at > >> > >> http://www.postgresql.org/about/donate > > > > -- > > Bruce Momjian bruce@momjian.us > > EnterpriseDB http://www.enterprisedb.com > > > > + If your life is a hard drive, Christ can be your backup. + > > > > -- > Jim Nasby jim@nasby.net > EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
"Jim C. Nasby" <jim@nasby.net> writes:
> Is there any reason not to make these casts implicit?
To the extent that you're trying to provide operators that should be
indexable, that won't solve the problem.
I'm unconvinced that these casts should be implicit anyway, as the types
are really considerably different than, say, int2 and int4 --- there are
no operations on int4 that "don't make sense" for an int2, the way there
are for polygon vs. box.
regards, tom lane