Re: pg_recvlogical requires -d but not described on the documentation - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: pg_recvlogical requires -d but not described on the documentation
Date
Msg-id CAExHW5v94uRcr4f3+yhLrLX8UeYusJB06mcSqfdvu8fYUmVc=Q@mail.gmail.com
Whole thread Raw
In response to RE: pg_recvlogical requires -d but not described on the documentation  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
List pgsql-hackers
On Fri, Feb 21, 2025 at 2:25 PM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> Dear Ashutosh,
>
> Thanks for the reply.
>
> > > 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.
>
> Something like attached, right? The fact that everyone has been set -d option
> may be strong.

This looks good to me. It builds with meson. Didn't check make.

>
> > > 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.
>
> Hmm, unify the treatment seems clean, but it may break current connection rules
> for some application. I'm not sure now this is helpful for users.

Hmm. I agree.

--
Best Wishes,
Ashutosh Bapat



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Missing [NO] INDENT flag in XMLSerialize backward parsing
Next
From: Nitin Jadhav
Date:
Subject: Fix crash during recovery when redo segment is missing