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>, "daniel@yesql.se" <daniel@yesql.se>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-07-07T05:36:14Z
Lists: pgsql-hackers 
On Tue, Jun 29, 2021 at 03:34:29PM -0400, Tom Lane wrote:
> Actually, I'd forgotten that the PQExpBuffer functions are already
> exported by libpq, and much of our frontend code already uses them
> from there.  So we don't really need to move anything unless there's
> a call to use this code in clients that don't use libpq, which are
> a pretty small set.
> 
> Also, having them be available both from libpq.so and from libpgcommon.a
> would be a tad problematic I think; it'd be hard to tell which way the
> linker would choose to resolve that.

Coming back to this thread.  You were thinking about switching to
PQExpBuffer for the error strings generated depending on error code
for the frontend, right?  Using a PQExpBuffer would be a problem if
attempting to get a more detailed error for pg_verifybackup, though I
guess that we can continue to live in this tool without this much
amount of details in the error strings.

It seems to me that this does not address yet the problems with the
palloc/pstrdup in jsonapi.c though, which would need to rely on
malloc() if we finish to use this code in libpq.  I am not sure yet
that we have any need to do that yet as we may finish by not using
OAUTH as SASL mechanism at the end in core.  So perhaps it would be
better to just give up on this thread for now?
--
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