| From: | David Steele <david(at)pgmasters(dot)net> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: making the backend's json parser work in frontend code |
| Date: | 2020-01-24 17:06:39 |
| Message-ID: | 8dff8ca3-7efa-a369-ef37-efdad5d2504a@pgmasters.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 1/24/20 10:00 AM, Alvaro Herrera wrote:
> On 2020-Jan-24, David Steele wrote:
>
>> It might be nice to have a strict mode where non-ASCII/UTF8 characters will
>> error instead, but that can be added on later.
>
> "your backup failed because you have a file we don't like" is not great
> behavior. IIRC we already fail when a file is owned by root (or maybe
> unreadable and owned by root), and it messes up severely when people
> edit postgresql.conf as root. Let's not add more cases of that sort.
My intention was that the strict mode would not be the default, so I
don't see why it would be a big issue.
> Maybe we can get away with *ignoring* such files, perhaps after emitting
> a warning.
I'd prefer an an error (or base64 encoding) rather than just skipping a
file. The latter sounds scary.
Regards,
--
-David
david(at)pgmasters(dot)net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Dilger | 2020-01-24 17:14:34 | Re: making the backend's json parser work in frontend code |
| Previous Message | Maciek Sakrejda | 2020-01-24 17:03:22 | Re: Duplicate Workers entries in some EXPLAIN plans |