On Fri, Dec 19, 2025 at 1:25 PM Fujii Masao <[email protected]> wrote: > > On Wed, Dec 3, 2025 at 2:45 PM Amit Kapila <[email protected]> wrote: > > > > On Tue, Dec 2, 2025 at 8:30 PM Fujii Masao <[email protected]> wrote: > > > > > > On Tue, Dec 2, 2025 at 9:08 PM Amit Kapila <[email protected]> > > > wrote: > > > > Is it possible that we append the predefined options to the options > > > > given by the user to avoid extra round-trip? > > > > > > One idea is to add a function, similar to > > > libpqrcv_get_dbname_from_conninfo() > > > in libpqwalreceiver.c, that extracts the options string from the conninfo, > > > to append the required fixed settings, and then to use the combined > > > string as > > > the value of the options parameter. > > > > > > > Yes, but libpqrcv_get_dbname_from_conninfo() is an exposed function, > > we can implement something internal for libpqwalreceiver.c like > > conninfo_add_defaults() present in fe-connect.c. > > > > > Do you think implementing this is worthwhile > > > to avoid the extra round trip? > > > > > > > I think so. Today, we have three variables, tomorrow there could be > > more such variables as well and apart from avoiding extra round trips, > > the idea to append options to provided options (if any) sounds more > > logical to me. > > OK, I've implemented the idea discussed upthread. The patch updates > libpqrcv_connect() so that, for logical replication, it extracts the options > string from the conninfo, appends the required fixed settings, and passes > the combined string as the options parameter to libpq. > > For example, if the conninfo specifies -c wal_sender_timeout=10s, > the resulting options value becomes: > > -c wal_sender_timeout=10s -c datestyle=ISO -c > intervalstyle=postgres -c extra_float_digits=3. > > Patch attached. >
Thanks, the idea looks good now. One minor comment: } + /* This appears to be an unnecessary addition in the patch. -- With Regards, Amit Kapila.
