Hi Nikolay,
Sorry for the late reply.
On Fri, Oct 11, 2019 at 7:54 PM Nikolay Shaplov <dhyan@nataraj.su> wrote:
> В письме от четверг, 10 октября 2019 г. 17:17:30 MSK пользователь Amit Langote
> написал:
> > I read comments that Tomas left at:
> > https://www.postgresql.org/message-id/20190727173841.7ypzo4xuzizvijge%40deve
> > lopment
> >
> > I'd like to join Michael in reiterating one point from Tomas' review.
> > I think the patch can go further in trying to make the code in this
> > area more maintainable.
> >
> > For example, even without this patch, the following stanza is repeated
> > in many places:
> >
> > options = parseRelOptions(reloptions, validate, foo_relopt_kind,
> > &numoptions);
> > rdopts = allocateReloptStruct(sizeof(FooOptions), options, numoptions);
> > fillRelOptions((void *) rdopts, sizeof(FooOptions), options, numoptions,
> > validate, foo_relopt_tab, lengthof(foo_relopt_tab)); return (bytea *)
> > rdopts;
> >
> > and this patch adds few more instances as it's adding more Options structs.
> >
> > I think it wouldn't be hard to encapsulate the above stanza in a new
> > public function in reloptions.c and call it from the various places
> > that now have the above code.
>
> The code of reloptions is very historical and illogical. I also noticed that
> these lines are repeated several time. And may be it would be better to put
> them into reloptions.c. But could anybody clearly explain what are they doing?
> Just to give function a proper name. I understand what they are doing, but I
> am unable to give short and clear explanation.
Maybe call it BuildRelOptions(), which takes in reloptions in the text
array format and returns a struct whose size is specified by the
caller. See the attached patch.
> I am planning to rewrite this part completely. So we have none of this lines
> repeated. I had a proposal you can see it here https://
> commitfest.postgresql.org/15/992/ but people on the list told be that patch is
> too complex and I should commit it part by part.
>
> So I am doing it now. I am almost done. But to provide clear and logical patch
> that introduces my concept, I need StdRdOption to be divided into separated
> structures. At least for AM. And I need at to be done as simply as possible
> because the rest of the code is going to be rewritten anyway.
>
> That is why I want to follow the steps: make the code uniform, and then
> improve it. I have improvement in the pocket, but I need a uniform code before
> revealing it.
>
> If you think it is absolutely necessary to put these line into one function, I
> will do it. It will not make code more clear, I guess. I See no benefits, but
> I can do it, but I would avoid doing it, if possible. At least at this step.
IMO, parts of the patch that only refactors the existing code should
be first in the list as it is easier to review, especially if it adds
no new concepts. In this case, your patch to break StdRdOptions into
more manageable chunks would be easier to understand if it built upon
a simplified framework of parsing reloptions text arrays.
Thanks,
Amit
