В письме от среда, 20 марта 2019 г. 6:15:38 MSK пользователь Iwata, Aya написал:
> You told us "big picture" about opclass around the beginning of this thread. > In my understanding, the purpose of this refactoring is to make reloptions > more flexible to add opclass. I understand this change may be needed for > opclass, however I think that this is not the best way to refactor > reloption. > > How about discussing more about this specification including opclass, and > finding the best way to refactor reloption? I have not read the previous > thread tightly, so you may have already started preparing. The idea is the following: now there are options that are build in (and actually nailed to) the postgres core. And there are options that can be created in Access Methods in extensions. They share some code, but not all of it. And it is bad. There should be one set of option-related code for both in-core relations and indexes, and for indexes from extensions. If this code is well written it can be used for opclass options as well. So we need to unnail options code from reloptions.c, so no options are nailed to it. So you need to move options definitions (at least for indexes) inside access method code. But we can't do it just that, because some indexes uses StdRdOptions structure for options, it is big, and indexes uses only fillfactor from there... What should we do? Create an individual Options structure for each index. So we did it. And now we have StdRdOptions that is used only for Heap and Toast. And Toast also does not use all of the variables of the structure. Why everywhere we have it's own option structure, but for Heap and Toast it is joined, and in not a very effective way? To successfully apply a patch I plan to commit I need a single option structure for each relation kind. Otherwise I will have to write some hack code around it. I do not want to do so. So it is better to get rid of StdRdOptions completely. This is the only purpose of this patch. Get rid of StdRdOptions and give each relation kind it's own option set. StdRdOptions is ancient stuff. I guess it were added when there was fillfactor only. Now life is more complex. Each relation kind has it's own set of options. Let's not mix them together! PS. If you wand to have some impression of what refactioring I am planning at the end, have a look at the patch https://commitfest.postgresql.org/15/992/ It is old, but you can get an idea.
