Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Nov 22, 2010 at 8:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> On balance I'm inclined to leave the unique key as per previous proposal
>> (with a "purpose" column) and add the which-sort-order-is-that
>> information as payload columns that aren't part of the key.
> This is probably OK too, although I confess I'm a lot less happy about
> it now that you've pointed out the need for those payload columns.
The reason I said "columns" is that I can foresee eventually wanting to
specify a pathkey in its entirety --- opfamily, asc/desc, nulls_first,
and whatever we come up with for collation. We don't currently need to
store more than the opfamily, since the others can never need to have
non-default values given the current implementation of KNNGIST. But the
idea that they might all be there eventually makes me feel that we don't
want to try to incorporate this data in pg_amop's unique key. 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.
regards, tom lane