On Tue, Nov 23, 2010 at 11:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Mon, Nov 22, 2010 at 11:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I'm satisfied to say that only one sort order can be associated with a
>>> particular operator in a particular opclass, which is what would be
>>> implied by using AMOP_SEARCH/AMOP_ORDER as the unique key component.
>
>> Does that imply that KNNGIST would only be able to support one
>> ordering per AMOP_ORDER-operator, or does it imply that each such
>> ordering would require a separate strategy number? The second might
>> be OK, but the first sounds bad.
>
> It would be the first, because simply assigning another strategy number
> only satisfies one of the unique constraints on pg_amop. To allow
> arbitrary flexibility here, we would have to include all components of
> the ordering specification in the unique constraint that's presently
> just (amopopr, amopfamily) and is proposed to become
> (amopopr, amopfamily, amoppurpose). I think that's an undue amount of
> complexity to support something that's most likely physically impossible
> from the index's standpoint anyway.
Or, you'd need to pass these details separately to the AM, which seems
like a more more flexible way of doing it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company