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

On 2020-01-24 18:56, Robert Haas wrote:
> On Fri, Jan 24, 2020 at 9:48 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>>> I prefer the encoding scheme myself. I don't see the point of the
>>> error.
>>
>> Yeah, if we don't want to skip such files, then storing them using
>> a base64-encoded name (with a different key than regular names)
>> seems plausible. But I don't really see why we'd go to that much
>> trouble, nor why we'd think it's likely that tools would correctly
>> handle a case that is going to have 0.00% usage in the field.
>
> I mean, I gave a not-totally-unrealistic example of how this could
> happen upthread. I agree it's going to be rare, but it's not usually
> OK to decide that if a user does something a little unusual,
> not-obviously-related features subtly break.

Another example might be log files under pg_log with localized weekday
or month names. (Maybe we're not planning to back up log files, but the
routines that deal with file names should probably be prepared to at
least look at the name and decide that they don't care about it rather
than freaking out right away.)

I'm not fond of the base64 idea btw., because it seems to sort of
penalize using non-ASCII characters by making the result completely not
human readable. Something along the lines of MIME would be better in
that way. There are existing solutions to storing data with metadata
around it.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services