В письме от понедельник, 7 октября 2019 г. 18:55:20 MSK пользователь Dent John
написал:
> I like the new approach. And I agree with the ambition — to split out the
> representation from StdRdOptions.
Thanks.
> However, with that change, in the AM’s *options() function, it looks as if
> you could simply add new fields to the relopt_parse_elt list. That’s still
> not true, because parseRelOptions() will fail to find a matching entry,
> causing numoptions to be left zero, and an early exit made. (At least,
> that’s if I correctly understand how things work.)
>
> I think that is fine as an interim limitation, because your change has not
> yet fully broken the connection to the boolRelOpts, intRelOpts, realRelOpts
> and stringRelOpts strutures. But perhaps a comment would help to make it
> clear. Perhaps add something like this above the tab[]: "When adding or
> changing a relopt in the relopt_parse_elt tab[], ensure the corresponding
> change is made to boolRelOpts, intRelOpts, realRelOpts or stringRelOpts."
Whoa-whoa!
I am not inventing something new here. Same code is already used in brin
(brin.c:820), gin (ginutils.c:602) and gist (gistutils.c:909) indexes. I've
just copied the idea, to do all index code uniform.
This does not mean that these code can't be improved, but as far as I can
guess it is better to do it in small steps, first make option code uniform, and
then improve all of it this way or another...
So I here I would suggest to discuss it I copied this code correctly, without
going very deeply into discussion how we can improve code I've used as a
source for cloning.
And then I have ideas how to do it better. But this will come later...
--
Software Developer: https://www.upwork.com/freelancers/~014a87e140ff02c0da
Body-oriented Therapist: https://vk.com/nataraj_rebalancing (Russian)