Thanks for your answer:)
>This is introduced by the commit 5a991ef, which allows logical
>decoding via walsender interface. The paramter replication has
>been there far from the commit intentionary as an 'undocumented
>paramter'. This is, I suppose, because it is treated as a part of
>the replication ptorocol, not a matter of ordinary clients at
>all.
Ah, this is intentional!
>Since it has no meaning out of the context of replication agents,
>it seems reasonable that the parameter is not documented in the
>section.
I see.
But, if this parameter is for logical decoding, I think it is better that
"46.3. Streaming Replication Protocol Interface" tells about this.
>Instead, the comment for libpqrcv_connect@libpqwalreceiver.c has
>become outedated by the commit.
>
>> * 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
>
>This should be synced with the document.
Agreed.
--
Takashi Ohnishi
2015-10-05 19:07 GMT+09:00 Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp>:
> Hello,
>
> At Fri, 2 Oct 2015 23:13:24 +0900, Takashi Ohnishi
> wrote in u2dwpl...@mail.gmail.com>
> > I found that it can be set like 'replication = true' in connection
> > parameter as documentation says in "50.3. Streaming Replication
> Protocol",
> > but this parameter is not denoted in "31.1.2. Parameter Key Words".
>
> This is introduced by the commit 5a991ef, which allows logical
> decoding via walsender interface. The paramter replication has
> been there far from the commit intentionary as an 'undocumented
> paramter'. This is, I suppose, because it is treated as a part of
> the replication ptorocol, not a matter of ordinary clients at
> all.
>
> > How about adding notation about this paramter in 31.1.2.?
> > Attached is a patch for that.
>
> Since it has no meaning out of the context of replication agents,
> it seems reasonable that the parameter is not documented in the
> section.
>
>
> Instead, the comment for libpqrcv_connect@libpqwalreceiver.c has
> become outedated by the commit.
>
> > * 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
>
> This should be synced with the document.
>
> Thoughts?
>
> ===
> diff --git a/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
> b/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
> index b7bbcf6..e58c35a 100644
> --- a/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
> +++ b/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
> @@ -94,10 +94,11 @@ libpqrcv_connect(char *conninfo)
>
> /*
> * 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.
> */
> keys[0] = "dbname";
> vals[0] = conninfo;
> ==
>
> regards,
>
> --
> Kyotaro Horiguchi
> NTT Open Source Software Center
>
>
