| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect |
| Date: | 2025-12-03 05:45:06 |
| Message-ID: | CAA4eK1JBg=k_4_0BX3p4usPs-a8-7FbPuPW8B2Rf1eUs5i_WLg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Dec 2, 2025 at 8:30 PM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>
> On Tue, Dec 2, 2025 at 9:08 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)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.
--
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | tianbing | 2025-12-03 05:46:37 | Re:Re: Add support for specifying tables in pg_createsubscriber. |
| Previous Message | Chao Li | 2025-12-03 05:41:44 | Re: [Proposal] Adding callback support for custom statistics kinds |