Horton

Re: [PATCH] Make jsonapi usable from libpq

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jacob Champion <pchampion@vmware.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Daniel Gustafsson <daniel@yesql.se>
Date: 2021-06-27T01:43:00Z
Lists: pgsql-hackers 
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

Commits

  1. Remove libpq's use of abort(3) to handle mutex failure cases.

  2. Don't use abort(3) in libpq's fe-print.c.

  3. Remove undesirable libpq dependency on stringinfo.c.

  4. Remove arbitrary line length limit for libpq service files.

  5. Use abort() instead of exit() to abort library functions