Re: making the backend's json parser work in frontend code
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
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-23T17:49:58Z
Lists: pgsql-hackers
On Thu, Jan 23, 2020 at 02:23:14PM -0300, Alvaro Herrera wrote:
> On 2020-Jan-23, Robert Haas wrote:
>
> > No, that's not it. Suppose that Álvaro Herrera has some custom
> > settings he likes to put on all the PostgreSQL clusters that he uses,
> > so he creates a file álvaro.conf and uses an "include" directive in
> > postgresql.conf to suck in those settings. If he also likes UTF-8,
> > then the file name will be stored in the file system as a 12-byte
> > value of which the first two bytes will be 0xc3 0xa1. In that case,
> > everything will be fine, because JSON is supposed to always be UTF-8,
> > and the file name is UTF-8, and it's all good. But suppose he instead
> > likes LATIN-1.
>
> I do have files with Latin-1-encoded names in my filesystem, even though
> my system is UTF-8, so I understand the problem. I was wondering if it
> would work to encode any non-UTF8-valid name using something like
> base64; the encoded name will be plain ASCII and can be put in the
> manifest, probably using a different field of the JSON object -- so for
> a normal file you'd have { path => '1234/2345' } but for a
> Latin-1-encoded file you'd have { path_base64 => '4Wx2YXJvLmNvbmYK' }.
> Then it's the job of the tool to ensure it decodes the name to its
> original form when creating/querying for the file.
>
> A problem I have with this idea is that this is very corner-casey, so
> most tool implementors will never realize that there's a need to decode
> certain file names.
Another idea is to use base64 for all non-ASCII file names, so we don't
need to check if the file name is valid UTF8 before outputting --- we
just need to check for non-ASCII, which is much easier. Another
problem, though, is how do you _flag_ file names as being
base64-encoded? Use another JSON field to specify that?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Commits
-
Add jsonapi.c to Mkvcbuild.pm's @pgcommonallfiles.
- 006b9dcad419 13.0 landed
-
Move jsonapi.c and jsonapi.h to src/common.
- beb4699091e9 13.0 landed
-
Move some code from jsonapi.c to jsonfuncs.c.
- 73ce2a03f30b 13.0 landed
-
Adjust pg_parse_json() so that it does not directly ereport().
- 1f3a021730be 13.0 landed
-
Remove jsonapi.c's lex_accept().
- 530609aa4263 13.0 landed
-
Split JSON lexer/parser from 'json' data type support.
- 11b5e3e35d39 13.0 landed
-
Rationalize code placement between wchar.c, encnames.c, and mbutils.c.
- 5afaa2e42655 13.0 landed
-
Move wchar.c and encnames.c to src/common/.
- e6afa8918c46 13.0 landed
-
Update header comments for wchar.c and encnames.c.
- 3d4cb5d6c180 13.0 landed
-
Make StringInfo available to frontend code.
- 26aaf97b683d 13.0 cited
-
Use SASLprep to normalize passwords for SCRAM authentication.
- 60f11b87a234 10.0 cited