| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | Matheus Alcantara <matheusssilv97(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 08:01:14 |
| Message-ID: | CAHGQGwEvZHhHWFp-9ikciyrKmsX7n-qvOixruMbP9pFH2VMnHQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, May 16, 2026 at 12:46 AM Matheus Alcantara
<matheusssilv97(at)gmail(dot)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 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?
> 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 having
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,
--
Fujii Masao
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nisha Moond | 2026-05-18 09:12:14 | Re: Proposal: Conflict log history table for Logical Replication |
| Previous Message | Jonathan Gonzalez V. | 2026-05-18 07:49:39 | [oauth] Fix minimal typo in OAuth |