On Sat, Oct 26, 2019 at 11:45 AM Michael Paquier <michael@paquier.xyz> wrote:
> On Fri, Oct 25, 2019 at 04:42:24PM +0900, Amit Langote wrote:
> > Hmm, if we're inventing a new API to replace the old one, why not use
> > that opportunity to be consistent with our general style, which
> > predominantly seems to be either words_separated_by_underscore() or
> > UpperCamelCase(). Thoughts?
>
> Not wrong. Using small-case characters separated with underscores
> would be more consistent with the rest perhaps? We use that for the
> initialization of custom variables and for all the relkind-related
> interfaces.
OK, I went with build_reloptions(), which looks very similar to nearby
exported functions.
> + * Parses reloptions provided by the caller in text array format and
> + * fills and returns a struct containing the parsed option values
> The sentence structure is weird, perhaps:
> This routine parses "reloptions" provided by the caller in text-array
> format. The parsing is done with a table describing the allowed
> options, defined by "relopt_elems" of length "num_relopt_elems". The
> returned result is a structure containing all the parsed option
> values.
Thanks, I have expanded the header comment based on your text.
> > Attached updated patch. It would be nice to hear whether this patch
> > is really what Nikolay intended to eventually do with this code.
>
> Okay, let's check if Nikolay likes this idea.
Attached updated patch.
Thanks,
Amit