Re: postgres_fdw: use_scram_passthrough on user mapping is ignored when also set on server

On Fri, May 15, 2026 at 5:19 AM Matheus Alcantara
<matheusssilv97(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Thu May 14, 2026 at 2:57 PM -03, Fujii Masao wrote:
> > use_scram_passthrough can be specified both on a foreign server and
> > on a user mapping. I found that when both are specified, currently
> > the server-level setting overrides the user mapping setting. Is this
> > precedence intentional?
> >
> > That seems inconsistent with the usual expectation that foreign server
> > options act as shared defaults, while user mapping options provide
> > per-user overrides. If the same option is specified in both places,
> > I would expect the user mapping setting to take precedence. Thoughts?
> >
> > If the current behavior is intentional, I'd like to document the precedence
> > when use_scram_passthrough is specified in both a foreign server and
> > a user mapping. Otherwise, I'd like to change postgres_fdw to prefer
> > the user mapping setting and update the documentation accordingly.
> >
>
> I agree that that user mapping setting should take precedence. The
> current behavior seems not correct since we are not able to
> enable/disable the scram passthrough to a specific user mapping.
>
> dblink also implement the same behavior, so I think that it should also
> be changed as postgres_fdw.
>
> The attached patches implement this change for postgres_fdw and dblink.

Thanks for the patches! They look good to me.

One minor comment: in UseScramPassthrough() in postgres_fdw/connection.c
and dblink.c, how about adding a comment like the following to clarify
the option precedence?

/*
* Return whether SCRAM pass-through is enabled.
*
* If use_scram_passthrough is specified in both the foreign server
* and the user mapping, the user mapping setting takes precedence.
*/

Also, while reviewing the use_scram_passthrough handling in dblink,
I found a separate issue: the option can be set via
ALTER FOREIGN DATA WRAPPER dblink_fdw, but that setting does not
seem to have any effect. Is this a bug? Like postgres_fdw, also in dblink,
we should disallow the option to be set at the foreign-data-wrapper level?
If yes, I think it would be better to address that as a separate patch.
Thought?

Regards,

--
Fujii Masao