Re: Rethinking representation of sort/hash semantics in queries and plans

I wrote:
> Now, this loss of flexibility doesn't particularly bother me, because
> I know of no existing or contemplated btree-substitute access methods.
> If one did appear on the horizon, there are a couple of ways we could
> fix the problem, the cleanest being to let a non-btree opfamily declare
> that it sorts the same as btree opfamily so-and-so.  Or we could fix
> it locally in plancat.c by performing the lookup-the-operators-and-
> then-the-btree-opfamilies dance on the fly when setting up IndexOptInfo
> for a non-btree amcanorder index.  But I'm disinclined to write such
> code when there's no way to test it and no foreseeable possibility
> that it'll ever be used.  Maybe we should just make plancat.c throw
> a not-implemented error if amcanorder is true but it's not btree.

On further reflection the last seems like clearly the thing to do.

> PS: the attached patch doesn't yet include removal of relcache
> rd_operator arrays, since that would just make the patch bigger
> without exposing any new issues.

And here's the complete patch.

			regards, tom lane