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@sss.pgh.pa.us> wrote:
>> Alvaro Herrera <alvherre@2ndquadrant.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