Re: libpq options

Поиск
Список
Период
Сортировка
От Şahap Aşçı
Тема Re: libpq options
Дата
Msg-id CAH8RQfVUNZd5H1aeNvNgVPHs-EfrmTc1bvNnBdhypVAE2MwiZg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: libpq options  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: libpq options
Список pgsql-docs
I think this solves the consistency issue that i am talking about. Well, i am just looking from documentation user point of view. If it's developer only option and shouldn't be documented then maybe adding a 'IDENTIFY_SYSTEM' parameter to pg_receivexlog is more appropriate. like this pg_receivexlog ... --identify-system On Sat, Nov 25, 2017 at 1:05 PM, Michael Paquier wrote: > On Wed, Nov 22, 2017 at 11:36 PM, Michael Paquier > wrote: > > Yeah, it is mainly a developer option which is why I guess it is not > > documented. Like you, I think it should be added as part of the > > connection parameter, and mentioned it a couple of days back: > > https://www.postgresql.org/message-id/CAB7nPqQAtKfG3H% > 2BuK11JNivtJtZYE9yVCrPuejRMjp8tUDe0nQ%40mail.gmail.com > > Attached is a patch as an attempt to bring together the best of both > worlds. The idea is to move the description of how the connection > parameter replication works from the replication protocol page into > the section of libpq dedicated to connection parameters, and add links > between both sections. > > Thoughts? > -- > Michael > -- Şahap Aşçı

В списке pgsql-docs по дате отправления:

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: PARALLEL in old syntax for CREATE AGGREGATE
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: libpq options