Re: [PATCH] Do not use StdRdOptions in Access Methods
От | Amit Langote |
---|---|
Тема | Re: [PATCH] Do not use StdRdOptions in Access Methods |
Дата | |
Msg-id | CA+HiwqGY_q-UiCcjnXqBimwO9nnDcka+N5Bw+HC1741RSByqWQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Do not use StdRdOptions in Access Methods (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: [PATCH] Do not use StdRdOptions in Access Methods
|
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: