Thread
-
Re: postgres_fdw: use_scram_passthrough on user mapping is ignored when also set on server
Fujii Masao <masao.fujii@gmail.com> — 2026-05-15T04:29:53Z
On Fri, May 15, 2026 at 5:19 AM Matheus Alcantara <matheusssilv97@gmail.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