On Sun, 2021-06-27 at 10:43 +0900, Michael Paquier wrote:
> 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
Right. So it really comes down to whether or not OAUTHBEARER support is
worth this additional complication, and that probably belongs to the
main thread on the topic.
But hey, we're getting some code cleanup out of the deal either way.
> 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.
It is definitely an option.
With the current architecture of the proof-of-concept, I feel like
forcing every client to implement JSON parsing just to be able to use
OAUTHBEARER would be a significant barrier to entry. Again, that's
probably conversation for the main thread.
> 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.
I think we should clean this up regardless.
--Jacob