[PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind

While working on patch for attribute options for indexes (see  
http://www.postgresql.org/message-id/5213596.TqFRiqmCTe@nataraj-amd64 )
I found out that code for reloptions is not flexible at all.

All definitions of attoptons are stored in central catalog in 
src/backend/access/common/reloptions.c
It is done this way for both heap and tuple relations, and also for all index 
access methods that goes with source code. 

Most of the code of the indexes is now hidden behind 
"access method" abstraction, but not the reloption code. If you grep through 
src/backend/access/common/reloptions.c, you will find RELOPT_KIND_GIN, 
RELOPT_KIND_BTREE, RELOPT_KIND_GIST, RELOPT_KIND_SPGIST, RELOPT_KIND_BRIN...

This all should me moved behind "access method" abstraction...

Custom indexes, like postgresql/contrib/bloom can add own reloptions, and 
relopt_kind. But the number of relopt_kinfd available is short (it would be 
enough for reloptions, but if we add attoptions, we will meet shortage soon).

So my proposial is the following: Each access method has it's own catalog of 
options (reloptions, and later attoptions) and when it want to call any 
function from src/backend/access/common/reloptions.c it uses a reference to 
that catalog instead of relopt_kind.

In the patch that is attached to this message, there is an idea of how it can 
be done.

In that patch I've left relopt_kind, and added refence to options catalog, 
and functions from reloptions.c uses that one that is defined. I've implemented 
"catalog reference" version for bloom index, and all the rest still work as 
they were.

In final patch there should be no relopt_kind at all, all descriptions of 
reloptions for indexes should go to src/backend/access/[am-name], reloptions 
for heap, toast, views and so on, should stay in 
src/backend/access/common/reloptions.c but should be stored as separate option 
catalog for each type. I still not sure what to do  with 
RELOPT_KIND_HEAP | RELOPT_KIND_TOAST options. But one or another solutions can 
be found...

-- 
Nikolay Shaplov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company