On 2024-Mar-14, Tom Lane wrote: > Michael Paquier <mich...@paquier.xyz> writes: > > Hmm. I am not sure how much protection this would offer, TBH. One > > thing that I find annoying with common/stringinfo.c as it is currently > > is that we have two exit() calls in the enlarge path, and it does not > > seem wise to me to spread that even more.
> I hope nobody is expecting that such code will get accepted. We have > a policy (and an enforcement mechanism) that libpq.so must not call > exit(). OAuth code in libpq will need to cope with using pqexpbuffer. FWIW that's exactly what Jacob's OAUTH patch does -- it teaches the relevant JSON parser code to use pqexpbuffer when in frontend environment, and continues to use StringInfo in backend. I find that a bit cumbersome, but if the idea of changing the StringInfo behavior (avoiding exit()) is too radical, then perhaps it's better that we go with Jacob's proposal in the other thread: +/* + * In backend, we will use palloc/pfree along with StringInfo. In frontend, use + * malloc and PQExpBuffer, and return JSON_OUT_OF_MEMORY on out-of-memory. + */ +#ifdef FRONTEND + +#define STRDUP(s) strdup(s) +#define ALLOC(size) malloc(size) + +#define appendStrVal appendPQExpBuffer +#define appendBinaryStrVal appendBinaryPQExpBuffer +#define appendStrValChar appendPQExpBufferChar +#define createStrVal createPQExpBuffer +#define resetStrVal resetPQExpBuffer +#define destroyStrVal destroyPQExpBuffer + +#else /* !FRONTEND */ + +#define STRDUP(s) pstrdup(s) +#define ALLOC(size) palloc(size) + +#define appendStrVal appendStringInfo +#define appendBinaryStrVal appendBinaryStringInfo +#define appendStrValChar appendStringInfoChar +#define createStrVal makeStringInfo +#define resetStrVal resetStringInfo +#define destroyStrVal destroyStringInfo + +#endif -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "Ni aún el genio muy grande llegaría muy lejos si tuviera que sacarlo todo de su propio interior" (Goethe)
