> On 28 Oct 2024, at 17:09, Jacob Champion <jacob.champ...@enterprisedb.com> > wrote: > On Mon, Oct 28, 2024 at 6:24 AM Daniel Gustafsson <dan...@yesql.se> wrote:
>> Looking more at the patchset I think we need to apply conditional compilation >> of the backend for oauth like how we do with other opt-in schemes in >> configure >> and meson. The attached .txt has a diff for making --with-oauth a >> requirement >> for compiling support into backend libpq. > > Do we get the flexibility we need with that approach? With other > opt-in schemes, the backend and the frontend both need some sort of > third-party dependency, but that's not true for OAuth. I could see > some people wanting to support an offline token validator on the > server side but not wanting to build the HTTP dependency into their > clients. Currently we don't support any conditional compilation which only affects backend or frontend, all --without-XXX flags turn it off for both. Maybe this is something which should change but I'm not sure that property should be altered as part of a patch rather than discussed on its own merit. > I was considering going in the opposite direction: With the client > hooks, a user could plug in their own implementation without ever > having to touch the built-in flow, and I'm wondering if --with-oauth > should really just be --with-builtin-oauth or similar. Then if the > server sends OAUTHBEARER, the client only complains if it doesn't have > a flow available to use, rather than checking USE_OAUTH. This kind of > ties into the other big open question of "what do we do about users > that don't want the additional overhead of something they're not > using?" We already know that GSS cause measurable performance impact on connections even when compiled but not in use [0], so I think we should be careful about piling on more. -- Daniel Gustafsson [0] 20240610181212.auytluwmbfl7l...@awork3.anarazel.de
