Re: Connection string parameter 'replication' in documentation

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: Connection string parameter 'replication' in documentation
Дата
Msg-id 20151007.114836.196245243.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Connection string parameter 'replication' in documentation  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Ouch!

At Tue, 6 Oct 2015 17:22:17 -0400, Robert Haas <robertmhaas@gmail.com> wrote in
<CA+TgmobZVq6E+LwuM=Sva358SQ-FrD-qEim8wPZka9sHWna6mw@mail.gmail.com>
> 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.

Thank you for your kindly replying this. I agree to the comment
above. It is my mistake that "in physical.." looks to qualify
"ignored" but no future in polishing it.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Etsuro Fujita
Дата:
Сообщение: Re: Obsolete comment in tidpath.c
Следующее
От: Etsuro Fujita
Дата:
Сообщение: Re: Foreign join pushdown vs EvalPlanQual