Re: [oauth] Split and extend PGOAUTHDEBUG - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: [oauth] Split and extend PGOAUTHDEBUG
Date
Msg-id CAOYmi+nmYjtQeNLcroJ2V=0hTTEumKz8ZHCXGT=04NOGSJA9=A@mail.gmail.com
Whole thread
In response to Re: [oauth] Split and extend PGOAUTHDEBUG  (Chao Li <li.evan.chao@gmail.com>)
List pgsql-hackers
On Tue, Mar 31, 2026 at 8:45 PM Chao Li <li.evan.chao@gmail.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



pgsql-hackers by date:

Previous
From: Sami Imseih
Date:
Subject: Re: Add pg_stat_autovacuum_priority
Next
From: Antonin Houska
Date:
Subject: Re: Adding REPACK [concurrently]