On Sat, Nov 20, 2010 at 1:51 PM, Tom Lane wrote:
>> If it's all right with you, I'll go ahead and commit this and then you
>> can break as much more stuff as you like. :-)
>
> Go for it.
Your turn.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Robert Haas writes:
> On Sat, Nov 20, 2010 at 1:37 PM, Tom Lane wrote:
>> I think your revised patch is incorrect, or at least not terribly safe,
>> to just remove the last DoneMatchingIndexKeys test and not replace it
>> with anything else.
Oh, now that I look at it I notice the after-the-fact
On Sat, Nov 20, 2010 at 1:37 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Nov 20, 2010 at 1:01 PM, Tom Lane wrote:
>>> But if you're going to do that, get rid of DoneMatchingIndexKeys
>>> altogether,
>
>> Sure. That's a giant crock.
>
>>> along with the extra zero that plancat.c adds to
Robert Haas writes:
> On Sat, Nov 20, 2010 at 1:01 PM, Tom Lane wrote:
>> But if you're going to do that, get rid of DoneMatchingIndexKeys
>> altogether,
> Sure. That's a giant crock.
>> along with the extra zero that plancat.c adds to the
>> opfamily array. We don't need to be using more tha
On Sat, Nov 20, 2010 at 1:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> I was looking at KNNGIST some more today and found myself trying to
>> disentangle what match_clause_to_indexcol() is actually doing. It
>> appears to me that the opfamily passed to that function is always the
>> same as i
Robert Haas writes:
> I was looking at KNNGIST some more today and found myself trying to
> disentangle what match_clause_to_indexcol() is actually doing. It
> appears to me that the opfamily passed to that function is always the
> same as index->opfamily[indexcol], which seems like needless
> no
I was looking at KNNGIST some more today and found myself trying to
disentangle what match_clause_to_indexcol() is actually doing. It
appears to me that the opfamily passed to that function is always the
same as index->opfamily[indexcol], which seems like needless
notational complexity. Maybe I'm
