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
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() |