Re: libpq options - Mailing list pgsql-docs

From Şahap Aşçı
Subject Re: libpq options
Date
Msg-id CAH8RQfVUNZd5H1aeNvNgVPHs-EfrmTc1bvNnBdhypVAE2MwiZg@mail.gmail.com
Whole thread Raw
In response to Re: libpq options  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: libpq options  (Michael Paquier <michael.paquier@gmail.com>)
List 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 by date:

Previous
From: Daniel Gustafsson
Date:
Subject: PARALLEL in old syntax for CREATE AGGREGATE
Next
From: Michael Paquier
Date:
Subject: Re: libpq options