Re: libpq options
От | Michael Paquier |
---|---|
Тема | Re: libpq options |
Дата | |
Msg-id | 20180305044439.GA2266@paquier.xyz обсуждение исходный текст |
Ответ на | Re: libpq options (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: libpq options
|
Список | pgsql-docs |
On Fri, Mar 02, 2018 at 12:58:50PM +0100, Magnus Hagander wrote: > To nitpick: > > + protocol. A Boolean value of <literal>true</literal> tells the > backend > > We don't really have boolean values here, do we? It's just the string true > that's treated as a boolean by the backend. It just sounds really weird to > me when written that way. Particularly since the next sentence talks about > passing "database" as the same thing. > > I know that's pretty much nitpicking, but I want to make sure I haven't > actually missed/forgotten how some part of that one is handled.. Yes, that's indeed a bit inconsistent with the other parameters able to use boolean-like parameters, like sslcompression or sslmode (deprecated in favor requiressl), still those two ones are frontend-only parameters, so they are just able to use "1" or "0". Replication is part of the startup packet which uses parse_bool() so valid values can be true, false, yes, no, on, off, 1 or 0. And it is even possible to use upper-case characters. So why not documenting all that precisely then? > It also talks separately about "going into walsender mode" (=physical > replication) and "instructs the walsender to connect to the database". I > think that's a bit confusing. I suggest just calling it "physical > replication mode" and "logical replication mode", and not bother mentioning > walsender since that's quite internal. Indeed, this term is pretty spread across the documentation as well. I have taken into account this feedback, and created the new version attached, for a v2. Thoughts? -- Michael
Вложения
В списке pgsql-docs по дате отправления: