Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Nov 23, 2010 at 11:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
A more flexible way of doing what? The first requirement here is that
the catalog entries provide sufficient information to determine the
semantics. You can't just say "this opclass supports ordering", you
have to specify what that ordering is. Punting to the index AM helps
not at all, unless your proposal is to hard-wire this in GIST rather
than in the core planner.
We will probably *also* want to pass these details explicitly to the
index AM, but that doesn't solve the problem that some catalog somewhere
has to say what it is that the opclass can do.
regards, tom lane
