Re: [PATCH] Do not use StdRdOptions in Access Methods
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Nikolay Shaplov <dhyan@nataraj.su>
Cc: pgsql-hackers@lists.postgresql.org, Amit Langote <amitlangote09@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Dent John <denty@qqdd.eu>, Thomas Munro <thomas.munro@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, "Iwata, Aya" <iwata.aya@jp.fujitsu.com>, Dmitry Dolgov <9erthalion6@gmail.com>
Date: 2019-11-22T07:34:05Z
Lists: pgsql-hackers
On Thu, Nov 21, 2019 at 09:39:53PM +0300, Nikolay Shaplov wrote: > BRIN_AM_OID and friends are defined in catalog/pg_am_d.h so for core indexes > we can do relation->rd_rel->relam == BRIN_AM_OID check. But for contrib > indexes we can't do such a thing. > Bloom index does not need such check as it uses options only when index is > created. At that point you can not choose wrong relation. But if in future we > will have some contrib index that uses options when it some data is inserted > (as it is done with fillfactor in core indexes) then index author will not be > able to do such relam check. I would not call it a big problem, but it is > something to think about, for sure... I don't think that you actually need that for custom index AMs anyway, as all code paths leading to the lookup of their reloption values is within the module they are defined in. > Thaks for joining this work, and sorry for late replies. Now I quite rarely > have time for postgres :-( We all have a life, don't worry. I am glad to see you around. -- Michael
Commits
-
Refactor reloption handling for index AMs in-core
- 4cb658af7002 13.0 landed
-
Cleanup code in reloptions.h regarding reloption handling
- 50d22de9325f 13.0 landed
-
Refactor code building relation options
- 3534fa223328 13.0 landed
-
Add some assertions to view reloption macros
- 396773762425 13.0 cited