MIME-Version: 1.0
References: 
 <CAN4CZFMmDZMH56O9vb_g7vHqAk8ryWFxBMV19C39PFghENg8kA@mail.gmail.com>
 <CAOYmi+k_et3yXpJ8op71-95j7OYg-kX5bWLgW9YTV_5G7f+O1A@mail.gmail.com>
 <CAOYmi+kivcSnazEJA=KWknd3azGYnU3mMq9SUvht5Zq74qNcYQ@mail.gmail.com>
 <CAN4CZFMKCB2OXPGW0R_hCSu4Gg==B7dBSrv6Mf-YuFcrUncADg@mail.gmail.com>
 <CAOYmi+kCYZ3YiOu+oSv1gVW6LXQaNg4BcEpskYizWgfV1z12kA@mail.gmail.com>
 <89B8BFC0-582F-4A59-97D3-1829EFA04E45@gmail.com>
In-Reply-To: <89B8BFC0-582F-4A59-97D3-1829EFA04E45@gmail.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Wed, 1 Apr 2026 10:05:30 -0700
Message-ID: 
 <CAOYmi+nmYjtQeNLcroJ2V=0hTTEumKz8ZHCXGT=04NOGSJA9=A@mail.gmail.com>
Subject: Re: [oauth] Split and extend PGOAUTHDEBUG
To: Chao Li <li.evan.chao@gmail.com>
Cc: Zsolt Parragi <zsolt.parragi@percona.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAOYmi%2BnmYjtQeNLcroJ2V%3D0hTTEumKz8ZHCXGT%3D04NOGSJA9%3DA%40mail.gmail.com>
Precedence: bulk

On Tue, Mar 31, 2026 at 8:45=E2=80=AFPM Chao Li <li.evan.chao@gmail.com> wr=
ote:
> +#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 ne=
ver be enabled in production.

Right.

--Jacob