Re: Connection string parameter 'replication' in documentation

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Connection string parameter 'replication' in documentation
Дата
Msg-id CA+TgmobZVq6E+LwuM=Sva358SQ-FrD-qEim8wPZka9sHWna6mw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Connection string parameter 'replication' in documentation  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Ответы Re: Connection string parameter 'replication' in documentation  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Foreign join pushdown vs EvalPlanQual
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Odd query execution behavior with extended protocol