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

From: "Matheus Alcantara" <matheusssilv97(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: postgres_fdw: use_scram_passthrough on user mapping is ignored when also set on server
Date: 2026-05-18 14:42:52
Message-ID: DILVRJ0YYTRC.1NDGAS1S7B456@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon May 18, 2026 at 5:01 AM -03, Fujii Masao wrote:
> Thanks for the patches!
>
> Neither dblink nor postgres_fdw seems to have tests checking whether options
> are specified at the proper object level (foreign server, user mapping, etc.).
> So adding the test for ALTER FOREIGN DATA WRAPPER ...
> (use_scram_passthrough ...)
> seems a bit overkill to me. Also, even if we decide to add such a test,
> it might be simpler to put it in sql/dblink.sql rather than as a TAP test.
> Thoughts?
>

I think that the test is worth to have to avoid such issues in the
future again, but I agree that adding as a TAP test is overkill. I've
moved to sql/dblink.sql on the new attached version.

Do you think that we need to add such test for postgres_fdw too?

>> Are you considering backporting these patches? I think that 0003 is
>> good, not sure about 0001 and 0002.
>
> I assume your concern is that v18 was already released with the current
> behavior, where the server-level use_scram_passthrough setting overrides
> the user-mapping-level one. Backpatching the behavior change to v18 could
> therefore affect existing users relying on that behavior, right?
>

Yes, you are right, this was my main concern.

> If the documentation had clearly stated that the user-mapping-level setting
> takes precedence, we could reasonably treat the current behavior as a bug
> and change it even in v18. But since there is no such documentation,
> I understand the hesitation.
>

Yeah, we don't have any documentation about this on 18, but we do have
for sslkey and sslcert where in postgres-fdw.sgml we have the following:
sslkey and sslcert - these may appear in either or both a connection
and a user mapping. If both are present, the user mapping setting
overrides the connection setting.

So I think that is desirable to have the same behavior for
use_scram_passthrough.

> That said, I'm feeling tempted to backpatch the change to v18, because having
> only v18 behave differently seems odd and potentially confusing...
>

I agree with this.

> The issue addressed by patch 0003 may have a similar concern. However,
> since use_scram_passthrough set on dblink_fdw currently has no effect
> even if there are existing users depending on that, it seems acceptable to
> change that behavior in v18. Is that your thinking?
>

Yes, you are right. Even if there are users that are relying on this it's
not working, so we at lest make it explicitly and avoid confusions.

Thank you for reviewing the patches!

--
Matheus Alcantara
EDB: https://www.enterprisedb.com

Attachment Content-Type Size
v3-0001-postgres_fdw-Allow-user-mapping-to-override-use_s.patch text/plain 5.2 KB
v3-0002-dblink-Allow-user-mapping-to-override-use_scram_p.patch text/plain 5.8 KB
v3-0003-dblink-Reject-use_scram_passthrough-option-on-for.patch text/plain 2.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jelte Fennema-Nio 2026-05-18 15:26:05 Re: meson: Make test output much more useful on failure (both in CI and locally)
Previous Message Daniel Gustafsson 2026-05-18 13:34:07 Re: [oauth] Fix minimal typo in OAuth