From: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> |
---|---|
To: | Andrew Tipton <andrew(dot)t(dot)tipton(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Patch: add GiST support for BOX @> POINT queries |
Date: | 2011-07-09 14:29:49 |
Message-ID: | CAP7Qgmkb91Dex3Gm6imngvtTYiSWgXJp01a+DaYs1u3w8UQ0CA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2011/6/19 Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>:
> 2011/6/17 Andrew Tipton <andrew(dot)t(dot)tipton(at)gmail(dot)com>:
>>
>> At this point I'm a bit lost -- while pg_amop.h has plenty of examples
>> of crosstype comparison operators for btree index methods, there are
>> none for GiST. Is GiST somehow a special case in this regard?
>
> It was I that was lost. As Tom mentioned, GiST indexes have records in
> pg_amop in their specialized way. I found gist_point_consistent has
> some kind of hack for that and pg_amop for point_ops records have
> multiple crosstype for that. So, if I understand correctly your first
> approach modifying gist_box_consistent was the right way, although
> trivial issues should be fixed. Also, you may want to follow point_ops
> when you are worried if the counterpart operator of commutator should
> be registered or not.
>
> Looking around those mechanisms, it occurred to me that you mentioned
> only box @> point. Why don't you add circly @> point, poly @> point as
> well as box? Is that hard?
>
It looks like the time to wrap up. I marked "Return with Feedback" on
this patch, since response from author has not come for a while. You
may think the fix was pretty easy and the patch be small, but more
general approach was preferred, I guess. Looking forward to seeing it
in better shape next time!
Thanks,
--
Hitoshi Harada
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2011-07-09 15:29:26 | Re: [HACKERS] Creating temp tables inside read only transactions |
Previous Message | Hitoshi Harada | 2011-07-09 14:23:20 | Re: Parameterized aggregate subquery (was: Pull up aggregate subquery) |