Re: making the backend's json parser work in frontend code - Mailing list pgsql-hackers

From Robert Haas
Subject Re: making the backend's json parser work in frontend code
Date
Msg-id CA+TgmoYbih=cNJfWAkEXFir17m7EXC2U6s7WxVT=iBOyqtYRrA@mail.gmail.com
Whole thread Raw
In response to Re: making the backend's json parser work in frontend code  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: making the backend's json parser work in frontend code  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: making the backend's json parser work in frontend code
Next
From: Peter Eisentraut
Date:
Subject: Re: Allow to_date() and to_timestamp() to accept localized names