| From: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
|---|---|
| To: | Nikolay Shaplov <dhyan(at)nataraj(dot)su> |
| Cc: | Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, VASUKI M <vasukianand0119(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, david(dot)g(dot)johnston(at)gmail(dot)com, Robert Haas <robertmhaas(at)gmail(dot)com>, myon(at)debian(dot)org |
| Subject: | Re: Custom oauth validator options |
| Date: | 2026-01-29 13:00:57 |
| Message-ID: | CAN4CZFMCh3vOWGPbU5pTB-bwnoAtgFuDJmGGv7z7xeez+WJiag@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> This patch suggests context independent API for managing extension
> defined sets of options. It is used for
> relation options and similar options, but cat be also used for any
> options sets, may be with small modifications.
>
> GUC options are almost same options as relation options. That is why, I
> guess, Alvaro suggested you to look at this patch.
Yes, but wouldn't that still require a generic refactoring of GUCs?
I'm not saying that would be a bad thing, but that's a big task in
itself.
But if I think about it in the general context of this thread (adding
extension options to pg_hba, ignoring the part that I tried to
implement it with GUCs in the current patch), that can be related.
Thanks for the clarification, I'll look into it in more detail.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ahmed Et-tanany | 2026-01-29 13:01:22 | Re: [PATCH] Add max_logical_replication_slots GUC |
| Previous Message | Euler Taveira | 2026-01-29 12:55:03 | Re: [PATCH] Add max_logical_replication_slots GUC |