Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
> On Mon, Aug 10, 2015 at 7:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
[ scratches head... ] I thought we'd just agreed we weren't going to keep
any of those pg_am columns? If we keep them, we'll have to define what
they mean for sequence AMs etc. ("Let them be NULL" would likely break
enough stuff that we might as well not have them.)
regards, tom lane
