Re: Connection string parameter 'replication' in documentation

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(at)libpqwalreceiver(dot)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(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>:

> Hello,
>
> At Fri, 2 Oct 2015 23:13:24 +0900, Takashi Ohnishi <bwtakacy(at)gmail(dot)com>
> wrote in <CAO38NOp66ST2K_0xGpQYe3cfsvSAgbkF4fYUg55b=
> U2dwPLQHw(at)mail(dot)gmail(dot)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(at)libpqwalreceiver(dot)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
>
>