Re: [PATCH] Make jsonapi usable from libpq

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jacob Champion <pchampion(at)vmware(dot)com>, "daniel(at)yesql(dot)se" <daniel(at)yesql(dot)se>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Make jsonapi usable from libpq
Date: 2021-07-07 05:36:14
Message-ID: YOU9TnKe8Pt7V1pn@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-07-07 05:42:00 Re: [PATCH] Make jsonapi usable from libpq
Previous Message Greg Nancarrow 2021-07-07 05:24:24 Re: row filtering for logical replication