public inbox for [email protected]  

help / color / mirror / Atom feed

From: Ashutosh Bapat <[email protected]>
To: Hayato Kuroda (Fujitsu) <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: pg_recvlogical requires -d but not described on the documentation
Date: Fri, 21 Feb 2025 16:22:54 +0530
Message-ID: <CAExHW5v94uRcr4f3+yhLrLX8UeYusJB06mcSqfdvu8fYUmVc=Q@mail.gmail.com> (raw)
In-Reply-To: <OSCPR01MB149660D1F436F8B82912FCB53F5C72@OSCPR01MB14966.jpnprd01.prod.outlook.com>
References: <OSCPR01MB14966930B4357BAE8C9D68A8AF5C72@OSCPR01MB14966.jpnprd01.prod.outlook.com>
	<CAExHW5uOprZgj2rVQ0HT3ckr+fVvhG-DvcVT+wfmwnwynH00pw@mail.gmail.com>
	<OSCPR01MB149660D1F436F8B82912FCB53F5C72@OSCPR01MB14966.jpnprd01.prod.outlook.com>

On Fri, Feb 21, 2025 at 2:25 PM Hayato Kuroda (Fujitsu)
<[email protected]> 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

view thread (20+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: pg_recvlogical requires -d but not described on the documentation
  In-Reply-To: <CAExHW5v94uRcr4f3+yhLrLX8UeYusJB06mcSqfdvu8fYUmVc=Q@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox