On Fri, Oct 15, 2010 at 9:39 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Oct 15, 2010 at 8:45 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Fri, Oct 15, 2010 at 8:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> Perhaps we should think of pg_amop not so much
>>>> as a way to tell the AM what to do, but just a way to tell it what
>>>> operator is logically involved without relying on the name or OID.
>>>
>>> I already think of it that way ...
>>
>> OK.
>
> Thinking about it that way, perhaps we could add an integer column
> amop_whats_it_good_for that gets used as a bit field. That wouldn't
> require changing the index structure, although it might break some
> other things.
I gave this a shot (though I called it amoppurpose rather than
amop_whats_it_good_for) and I think it's a reasonable way to proceed.
Proof-of-concept patch attached. This just adds the column (using the
existing padding space), defines AMOP_SEARCH and AMOP_ORDER, and makes
just about everything ignore anything not marked AMOP_SEARCH,
attached. This would obviously need some more hacking to pay
attention to AMOP_ORDER where relevant, etc. and to create some actual
syntax around it. Currently CREATE OPERATOR CLASS / ALTER OPERATOR
FAMILY have this bit:
OPERATOR strategy_number ( op_type [ , op_type ] )
knngist-0.9 implements this:
[ORDER] OPERATOR strategy_number ( op_type [, op_type ] )
...but with the design proposed above that's not quite what we'd want,
because amoppurpose is a bit field, so you could have one or both of
the two possible purposes. Perhaps:
OPERATOR strategy_number ( op_type [ , op_type ] ) [ FOR { SEARCH |
ORDER } [, ...] ]
With the default being FOR SEARCH.
Comments?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company