From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | bwtakacy(at)gmail(dot)com, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Connection string parameter 'replication' in documentation |
Date: | 2015-10-06 21:22:17 |
Message-ID: | CA+TgmobZVq6E+LwuM=Sva358SQ-FrD-qEim8wPZka9sHWna6mw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 5, 2015 at 6:07 AM, Kyotaro HORIGUCHI
<horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-10-06 21:43:48 | Re: Odd query execution behavior with extended protocol |
Previous Message | Robert Haas | 2015-10-06 21:19:04 | Re: Foreign join pushdown vs EvalPlanQual |