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

On Tue, May 24, 2016 at 10:12 AM, Nikolay Shaplov
<n(dot)shaplov(at)postgrespro(dot)ru> wrote:
> 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...

+1 for that concept. I'm not sure whether your implementation is good
or bad because I haven't really looked at it, but I agree that the way
the reloption stuff is structured is a nuisance, and injecting more
abstraction there seems like a good thing.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company