MIME-Version: 1.0
References: 
 <CAHGQGwEJ8rZjmbOvCicyr4vbuLio082bNTde0WNoSWaWr9wVcg@mail.gmail.com>
 <DIIOEOI2RTVC.1J8PO0GO2VZIG@gmail.com>
 <CAHGQGwGXpYs+Hw+xqLacVtgS_ztwQ2hm1LeK8q=cMvGLYzB0HA@mail.gmail.com>
 <DIJD8SBZQK54.1L75HI5SLG2LT@gmail.com>
In-Reply-To: <DIJD8SBZQK54.1L75HI5SLG2LT@gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
Date: Mon, 18 May 2026 17:01:14 +0900
Message-ID: 
 <CAHGQGwEvZHhHWFp-9ikciyrKmsX7n-qvOixruMbP9pFH2VMnHQ@mail.gmail.com>
Subject: Re: postgres_fdw: use_scram_passthrough on user mapping is ignored
 when also set on server
To: Matheus Alcantara <matheusssilv97@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAHGQGwEvZHhHWFp-9ikciyrKmsX7n-qvOixruMbP9pFH2VMnHQ%40mail.gmail.com>
Precedence: bulk

On Sat, May 16, 2026 at 12:46=E2=80=AFAM Matheus Alcantara
<matheusssilv97@gmail.com> wrote:
> >     /*
> >      * 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.
> >      */
> >
>
> Sounds good, fixed.

Thanks!


> Yeah, good catch, this is from 3642df265d0. The problem is that
> dblink_fdw_validator() was changed to call is_valid_dblink_fdw_option()
> instead of is_valid_dblink_option() to make CRETE SERVER ... OPTIONS
> (use_scram_passthrough '...'); works but I miss the fact that it's also
> used by ALTER FOREIGN DATA WRAPPER. The new attached 0003 fix this by
> only checking the fdw options when the validator context is from foreign
> server or user mapping.

Thanks for the patches!

Neither dblink nor postgres_fdw seems to have tests checking whether option=
s
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?


> 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?

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.

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

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?

Regards,

--=20
Fujii Masao