Re: Connection string parameter 'replication' in documentation - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Connection string parameter 'replication' in documentation
Date
Msg-id CA+TgmobZVq6E+LwuM=Sva358SQ-FrD-qEim8wPZka9sHWna6mw@mail.gmail.com
Whole thread Raw
In response to Re: Connection string parameter 'replication' in documentation  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: Connection string parameter 'replication' in documentation
List pgsql-hackers
On Mon, Oct 5, 2015 at 6:07 AM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:
>         /*
>          * We use the expand_dbname parameter to process the connection string (or
> -        * URI), and pass some extra options. The deliberately undocumented
> -        * parameter "replication=true" makes it a replication connection. The
> -        * database name is ignored by the server in replication mode, but specify
> -        * "replication" for .pgpass lookup.
> +        * URI), and pass some extra options. The paramter "replication"
> +        * deliberately documented out of the section for the ordiary client
> +        * protocol, having "true" makes it a physical replication connection. The
> +        * database name is ignored by the server in physical replication mode,
> +        * but specify "replication" for .pgpass lookup.
>          */

I don't think this is an improvement, even ignoring the fact that
you've spelled a couple of words incorrectly.  The original text seems
clear enough, and the new text isn't really fully accurate either: the
discussion of when the database name is ignored really shouldn't be
linked to whether this is logical or physical replication.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Foreign join pushdown vs EvalPlanQual
Next
From: Robert Haas
Date:
Subject: Re: Odd query execution behavior with extended protocol