| From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [oauth] Split and extend PGOAUTHDEBUG |
| Date: | 2026-04-01 17:05:30 |
| Message-ID: | CAOYmi+nmYjtQeNLcroJ2V=0hTTEumKz8ZHCXGT=04NOGSJA9=A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Mar 31, 2026 at 8:45 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
> +#define OAUTHDEBUG_UNSAFE_HTTP (1<<0)
>
> Since the flags are defined as uint32, does it make sense to define these flag constants as ((uint32) 1 << 0)?
No, I don't think so. (If we ever got to <<31 we'd need to switch to
1U instead of 1, I think, but I still wouldn't want to write it as a
cast. Bitflags are in pretty wide use across our codebase and I don't
want to introduce a new spelling.)
> 2 oauth_get_debug_flags() reparses PGOAUTHDEBUG every time it is called, which feels a bit unnecessary.
We could maybe rename it oauth_parse_debug_flags(), so it's at least
not hidden/surprising?
> But I don't think this is a big deal, since these debug options should never be enabled in production.
Right.
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Antonin Houska | 2026-04-01 17:06:53 | Re: Adding REPACK [concurrently] |
| Previous Message | Sami Imseih | 2026-04-01 16:58:44 | Re: Add pg_stat_autovacuum_priority |