В письме от среда, 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.
