Re: making the backend's json parser work in frontend code

Alvaro Herrera <alvherre@2ndquadrant.com>

From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Mark Dilger <mark.dilger@enterprisedb.com>, David Steele <david@pgmasters.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2020-01-23T18:20:27Z
Lists: pgsql-hackers
On 2020-Jan-23, Bruce Momjian wrote:

> On Thu, Jan 23, 2020 at 01:05:50PM -0500, Robert Haas wrote:
> > > Another
> > > problem, though, is how do you _flag_ file names as being
> > > base64-encoded?  Use another JSON field to specify that?
> > 
> > Alvaro's proposed solution in the message to which you replied was to
> > call the field either 'path' or 'path_base64' depending on whether
> > base-64 escaping was used. That seems better to me than having a field
> > called 'path' and a separate field called 'is_path_base64' or
> > whatever.
> 
> Hmm, so the JSON key name is the flag --- interesting.

Yes, because if you use the same key name, you risk a dumb tool writing
the file name as the encoded name.  That's worse because it's harder to
figure out that it's wrong.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Commits

  1. Add jsonapi.c to Mkvcbuild.pm's @pgcommonallfiles.

  2. Move jsonapi.c and jsonapi.h to src/common.

  3. Move some code from jsonapi.c to jsonfuncs.c.

  4. Adjust pg_parse_json() so that it does not directly ereport().

  5. Remove jsonapi.c's lex_accept().

  6. Split JSON lexer/parser from 'json' data type support.

  7. Rationalize code placement between wchar.c, encnames.c, and mbutils.c.

  8. Move wchar.c and encnames.c to src/common/.

  9. Update header comments for wchar.c and encnames.c.

  10. Make StringInfo available to frontend code.

  11. Use SASLprep to normalize passwords for SCRAM authentication.