On Mon, Aug 10, 2015 at 7:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@2ndquadrant.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.
