[PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind
От | Nikolay Shaplov |
---|---|
Тема | [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind |
Дата | |
Msg-id | 4636505.Bu9AKW1Kzc@nataraj-amd64 обсуждение исходный текст |
Ответы |
Re: [PROPOSAL] Move all am-related reloption code into
src/backend/access/[am-name] and get rid of relopt_kind
Re: [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind Re: [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind |
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: