On Tue, May 24, 2016 at 10:12 AM, Nikolay Shaplov <n.shap...@postgrespro.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
