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
