On Wed, Mar 04, 2020 at 10:58:31PM +0300, Nikolay Shaplov wrote: > But the truth is that my goal is to move all code that defines all option > names, min/max values etc, move it inside am code. To move data from > boolRelOpts, intRelOpts, realRelOpts, enumRelOpts, enumRelOpts from > reloptions.c into the code that implement AMs that uses these options. > > I did it for indexes in patch I've offered several years ago. Now we have > also > relaion AM. > > But I would prefer to fix index AM relioptions first, and then copy that > solution for relations.
How do you think that this part should be changed then, if this needs any changes? It seems to me that we have a rather correct layer for index AMs by requiring each one to define the available option set using indoptions through their handler, with option fetching macros located within each AM. > Because if I first copy AM solution from indexes to relation, then I will > have > to fix it in two places. > > So I would prefer to keep reloptions for relations in relations.c, only split > them into HeapOptions and ToastOptions, then change AM for indexes moving > option definition into AM's and then clone the solution for relations. Then, for table AMs, it seems to me that you are right for long-term perspective to have the toast-related options in reloptions.c, or perhaps directly located within more toast-related file (?) as table AMs interact with toast using heapam_relation_needs_toast_table and such callbacks. So for heap, moving the option handling to roughly heapam_handler.c is a natural move, though this requires a redesign of the existing structure to use option handling closer to what indoptions does, but for tables. -- Michael
signature.asc
Description: PGP signature
