Re: making the backend's json parser work in frontend code
От | David Steele |
---|---|
Тема | Re: making the backend's json parser work in frontend code |
Дата | |
Msg-id | ac9cabb7-acbd-e153-2785-a9f37721c167@pgmasters.net обсуждение исходный текст |
Ответ на | Re: making the backend's json parser work in frontend code (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: making the backend's json parser work in frontend code
|
Список | pgsql-hackers |
On 1/23/20 11:05 AM, Robert Haas wrote: > On Thu, Jan 23, 2020 at 12:49 PM Bruce Momjian <bruce@momjian.us> wrote: >> 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. > > I think that we have the infrastructure available to check in a > convenient way whether it's valid as UTF-8, so this might not be > necessary, but I will look into it further unless there is a consensus > to go another direction entirely. > >> 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. +1. I'm not excited about this solution but don't have a better idea. It might be nice to have a strict mode where non-ASCII/UTF8 characters will error instead, but that can be added on later. Regards, -- -David david@pgmasters.net
В списке pgsql-hackers по дате отправления: