On Sat, Jun 26, 2021 at 01:43:50PM -0400, Tom Lane wrote: > BTW, so far as the original topic of this thread is concerned, > it sounds like Jacob's ultimate goal is to put some functionality > into libpq that requires JSON parsing. I'm going to say up front > that that sounds like a terrible idea. As we've just seen, libpq > operates under very tight constraints, not all of which are > mechanically enforced. I am really doubtful that anything that > would require a JSON parser has any business being in libpq. > Unless you can sell us on that point, I do not think it's worth > complicating the src/common JSON code to the point where it can > work under libpq's constraints.
AFAIK, the SASL mechanism OAUTHBEARER described in RFC 7628 would require such facilities as failures are reported in this format: https://datatracker.ietf.org/doc/html/rfc7628 Perhaps you are right and we have no need to do any json parsing in libpq as long as we pass down the JSON blob, but I am not completely sure if we can avoid that either. Separate topic: I find disturbing the dependency of jsonapi.c to the logging parts just to cope with dummy error values that are originally part of JsonParseErrorType. -- Michael
signature.asc
Description: PGP signature
