On Tue, Nov 23, 2010 at 11:12 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Nov 22, 2010 at 11:05 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
