Re: [PoC] Federated Authn/z with OAUTHBEARER
От | Jacob Champion |
---|---|
Тема | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Дата | |
Msg-id | CAOYmi+n9qa3+fM0u5+=9vvr+TirM54Y8NMDUpPBn-8xLGHcFgw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PoC] Federated Authn/z with OAUTHBEARER (Peter Eisentraut <peter@eisentraut.org>) |
Список | pgsql-hackers |
On Mon, Aug 26, 2024 at 1:18 AM Peter Eisentraut <peter@eisentraut.org> wrote: > Or, if people find that too scary, something like > > #ifdef JSONAPI_USE_PQEXPBUFFER > > #define jsonapi_StringInfo PQExpBuffer > [...] > > That way, it's at least more easy to follow the source code because > you see a mostly-familiar API. 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. > Also, we should make this PQExpBuffer-using mode only used by libpq, > not by frontend programs. So libpq takes its own copy of jsonapi.c > and compiles it using JSONAPI_USE_PQEXPBUFFER. That will make the > libpq build descriptions a bit more complicated, but everyone who is > not libpq doesn't need to change. Sounds reasonable. 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... > Or maybe there is a clever way to avoid even that: Create a > fixed JsonLexContext like > > static const JsonLexContext failed_oom; > > and on OOM you return that one from makeJsonLexContext*(). And then > in pg_parse_json(), when you get handed that context, you return > JSON_OUT_OF_MEMORY immediately. I like this idea. Thanks! --Jacob
В списке pgsql-hackers по дате отправления: