Re: [PoC] Federated Authn/z with OAUTHBEARER

On Mon, Aug 26, 2024 at 4:23 PM Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> I was having trouble reasoning about the palloc-that-isn't-palloc code
> during the first few drafts, so I will try a round with the jsonapi_
> prefix.

v27 takes a stab at that. I have kept the ALLOC/FREE naming to match
the strategy in other src/common source files.

The name of the variable JSONAPI_USE_PQEXPBUFFER leads to sections of
code that look like this:

+#ifdef JSONAPI_USE_PQEXPBUFFER
+ if (!new_prediction || !new_fnames || !new_fnull)
+ return false;
+#endif

To me it wouldn't be immediately obvious why "using PQExpBuffer" has
anything to do with this code; the key idea is that we expect any
allocations to be able to fail. Maybe a name like JSONAPI_ALLOW_OOM or
JSONAPI_SHLIB_ALLOCATIONS or...?

> It complicates the test coverage situation a little
> bit, but I think my current patch was maybe insufficient there anyway,
> since the coverage for the backend flavor silently dropped...

To do this without too much pain, I split the "forbidden" objects into
their own shared library, used only by the JSON tests which needed
them. I tried not to wrap too much ceremony around them, since they're
only needed in one place, so they don't have an associated Meson
dependency object.

> > Or maybe there is a clever way to avoid even that: Create a
> > fixed JsonLexContext like
> >
> > static const JsonLexContext failed_oom;

I think this turned out nicely. Two slight deviations from this are
that we can't return a pointer-to-const, and we also need an OOM
sentinel for the JsonIncrementalState, since it's possible to
initialize incremental parsing into a JsonLexContext that's on the
stack.

--Jacob