public inbox for [email protected]
help / color / mirror / Atom feedFrom: Fujii Masao <[email protected]>
To: Matheus Alcantara <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: postgres_fdw: use_scram_passthrough on user mapping is ignored when also set on server
Date: Sat, 23 May 2026 10:58:40 +0900
Message-ID: <CAHGQGwFqBFkPzxfBad-1YzRPbapCq9TdXQC7zmSeqNisXyq6Gw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAHGQGwEJ8rZjmbOvCicyr4vbuLio082bNTde0WNoSWaWr9wVcg@mail.gmail.com>
<[email protected]>
<CAHGQGwGXpYs+Hw+xqLacVtgS_ztwQ2hm1LeK8q=cMvGLYzB0HA@mail.gmail.com>
<[email protected]>
<CAHGQGwEvZHhHWFp-9ikciyrKmsX7n-qvOixruMbP9pFH2VMnHQ@mail.gmail.com>
<[email protected]>
On Mon, May 18, 2026 at 11:42 PM Matheus Alcantara
<[email protected]> wrote:
> 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?
No, I don't think so.
In dblink, use_scram_passthrough is handled by a dblink-specific validation
path, and patch 0003 fixes that specific code path. So it might be worth
adding such test for dblink.
In postgres_fdw, however, this option is handled by the generic option/context
validation machinery, not by any special-case code. We already have tests for
context-sensitive option validation there. So adding such test for postgres_fdw
would be mostly redundant, I think. Thought?
> 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.
Agreed. I'm therefore thinking of backpatching patches 0001 and 0002 to v18.
Even in v18, this change is very narrow. It only affects cases where
use_scram_passthrough is specified at both the server and user-mapping levels
with conflicting values. In such cases, the natural interpretation is that
the user-mapping setting is intended to override the server-level setting;
otherwise, there would be little reason to specify conflicting values.
Given the limited impact, leaving v18 as the only branch with different
semantics for a feature introduced in v18 seems more undesirable and
potentially confusing. So I think backpatching to v18 makes sense.
Regards,
--
Fujii Masao
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: postgres_fdw: use_scram_passthrough on user mapping is ignored when also set on server
In-Reply-To: <CAHGQGwFqBFkPzxfBad-1YzRPbapCq9TdXQC7zmSeqNisXyq6Gw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox