Re: WIP: Rework access method interface

On Mon, Aug 10, 2015 at 7:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> > Tom Lane wrote:
> >> I think that's likely for the best anyway; there are too many catalogs
> >> that think a pg_am OID identifies an index AM. Better to create other
> >> catalogs for other types of AMs.
>
> > That means we won't be able to reuse pg_class.relam as a pointer to the
> > AM-of-the-other-kind either.
>
> Hm. So one way or the other we're going to end up violating relational
> theory somewhere. OK, I yield: let's say that pg_am has amname, amkind,
> amhandler, and nothing else. Then we will need SQL functions to expose
> whatever information we think needs to be available to SQL code.
>

There is second revision of this patch. Changes are so:

* AmRoutine was renamed to IndexAmRoutine assuming there could be other
access methods in the future.
* amhandlers now return index_am_handler pseudotype.
* CHECK_PROCEDUREs are now is the place of original GET_REL_PROCEDUREs.
* amstrategies, amsupport, amcanorderbyop, amstorage, amkeytype are in
both pg_am and IndexAmRoutine. Consistence of amhandler answer and pg_am
tuple is checking.
* Some comments and refactoring.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company