From: Jacob Champion <pchampion@vmware.com>
To: michael@paquier.xyz <michael@paquier.xyz>
To: tgl@sss.pgh.pa.us <tgl@sss.pgh.pa.us>
Cc: daniel@yesql.se <daniel@yesql.se>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH] Make jsonapi usable from libpq
Date: Tue, 29 Jun 2021 18:09:43 +0000
Message-ID: <8e91a462b305919bcae98bb4aca286fe696ce76f.camel@vmware.com> (raw)
In-Reply-To: <YNfXpFeBVfU2HsVe@paquier.xyz>
References: <a250d475ba1c0cc0efb7dfec8e538fcc77cdcb8e.camel@vmware.com>
<YNQedHwheUaTnnGt@paquier.xyz>
<daeb22ec6ca8ef61e94d766a9b35fb03cabed38e.camel@vmware.com>
<YNZ2mnsbDVJQrA/a@paquier.xyz>
<3045186.1624729430@sss.pgh.pa.us>
<YNfXpFeBVfU2HsVe@paquier.xyz>
On Sun, 2021-06-27 at 10:43 +0900, Michael Paquier wrote:
> 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
Right. So it really comes down to whether or not OAUTHBEARER support is
worth this additional complication, and that probably belongs to the
main thread on the topic.
But hey, we're getting some code cleanup out of the deal either way.
> 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.
It is definitely an option.
With the current architecture of the proof-of-concept, I feel like
forcing every client to implement JSON parsing just to be able to use
OAUTHBEARER would be a significant barrier to entry. Again, that's
probably conversation for the main thread.
> 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.
I think we should clean this up regardless.
--Jacob
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pchampion@vmware.com, michael@paquier.xyz, tgl@sss.pgh.pa.us, daniel@yesql.se
Subject: Re: [PATCH] Make jsonapi usable from libpq
In-Reply-To: <8e91a462b305919bcae98bb4aca286fe696ce76f.camel@vmware.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox