Re: match_clause_to_indexcol()

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Date: 2010-11-20T18:33:24Z
Lists: pgsql-hackers

Attachments

On Sat, Nov 20, 2010 at 1:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> 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
>> notational complexity.  Maybe I'm missing something, but the attached
>> patch seems to make things simpler and clearer.  Thoughts?
>
> +1.  I think the existing coding dates from a time when we didn't have
> IndexOptInfo at all, or at least didn't pass it around to all these
> sub-functions, so there was no other path for getting at the info.
>
> 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 than one way to
> iterate over those arrays.

I am slightly worried that this might break third-party code, or even
some part of the core code that's still using the old system.  I don't
mind if you want to rip it out, but personally, I'd rather leave that
part well enough alone.  Revised patch attached.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company