On Sat, Oct 16, 2010 at 9:54 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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?
And here's the attachment, sorry.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company