Re: pg_recvlogical requires -d but not described on the documentation
От | Ashutosh Bapat |
---|---|
Тема | Re: pg_recvlogical requires -d but not described on the documentation |
Дата | |
Msg-id | CAExHW5v94uRcr4f3+yhLrLX8UeYusJB06mcSqfdvu8fYUmVc=Q@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: pg_recvlogical requires -d but not described on the documentation ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
Ответы |
RE: pg_recvlogical requires -d but not described on the documentation
|
Список | 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 по дате отправления: