On Fri, Dec 19, 2025 at 1:25 PM Fujii Masao <masao.fujii@gmail.com> wrote:
>
> On Wed, Dec 3, 2025 at 2:45 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Tue, Dec 2, 2025 at 8:30 PM Fujii Masao <masao.fujii@gmail.com> wrote:
> > >
> > > On Tue, Dec 2, 2025 at 9:08 PM Amit Kapila <amit.kapila16@gmail.com> 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.
