Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect

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.

In response to

Browse pgsql-hackers by date

  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