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>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se>
Subject: Re: [PATCH] Make jsonapi usable from libpq
Date: 2021-06-27 01:43:00
Message-ID: YNfXpFeBVfU2HsVe@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Elijah Stone 2021-06-27 02:01:47 Re: Composite types as parameters
Previous Message Michael Paquier 2021-06-27 01:30:23 Re: Pipeline mode and PQpipelineSync()