Re: Connection string parameter 'replication' in documentation

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

In response to

Responses

Browse pgsql-hackers by date

  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