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
