Re: pg_recvlogical requires -d but not described on the documentation

On Fri, Feb 21, 2025 at 9:56 AM Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
>
> Dear hackers,
>
> Hi, I found the issue $SUBJECT. According to the doc [1]:
>
> ```
> -d dbname
> --dbname=dbname
> The database to connect to. See the description of the actions for what this means in detail.
> The dbname can be a connection string. If so, connection string parameters will override any
> conflicting command line options. Defaults to the user name.
> ```
>
> IIUC final statement implies --dbname can be omitted. If it is mandatory, it should be described
> in the synopsis part - not written now. However, the command would fail when -d is missed.
>
> ```
> $ pg_recvlogical -U postgres --start -S test -f -
> pg_recvlogical: error: no database specified
> pg_recvlogical: hint: Try "pg_recvlogical --help" for more information.
> ```
>
> ISTM the inconsistency is introduced since the initial commit. I think they should be unified either
> 1) update the doc or 2) accept when -d is not specified. Personally, I like 2nd approach, pg_recvlogical
> can follow the normal connection rule. I.e.,
>

Given that the discrepancy has survived so long, it seems that users
always pass -d. And to some extent, requiring users to specify a
database instead of defaulting to one is safer practice. This avoids
users fetching changes from unexpected database/slot and cause further
database inconsistencies on the receiver side. I would just fix
documentation in this case.

> a) Use PGDATABASE if specified
> b) Check 'U' and PGUSER and use it if specified
> c) Otherwise use the current OS user name

If we want to go this route, it will be good to unify the treatment of
-d option at one place in code and reuse it everywhere. Thanks to your
investigations, we are seeing too many descripancies in -d option
being used in many utilities. Fixing all at once would be good. Also
it will be good to similarly unify documentation by writing -d
documentation at only place and reusing it everywhere. But I don't
know whether our documentation allows modularization and code-reuse.

--
Best Wishes,
Ashutosh Bapat