> 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
In response to
pgsql-hackers by date
|Next:||From: Greg Stark||Date: 2010-11-29 00:42:28|
|Subject: Re: Report: Linux huge pages with Postgres|
|Previous:||From: Tom Lane||Date: 2010-11-29 00:34:34|
|Subject: Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements. |