> On 15 Mar 2024, at 09:38, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> On 2024-Mar-14, Tom Lane wrote:
>
>> Michael Paquier <michael@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:
Correct, the OAuth work does not make any claims to use StringInfo in libpq.
My understanding of this thread was to make it use StringInfo for now to get
this available for frontend binaries now, and reduce scope here, and later
change it up if/when the OAuth patch lands.
--
Daniel Gustafsson