Re: making the backend's json parser work in frontend code
От | Robert Haas |
---|---|
Тема | Re: making the backend's json parser work in frontend code |
Дата | |
Msg-id | CA+TgmoYbih=cNJfWAkEXFir17m7EXC2U6s7WxVT=iBOyqtYRrA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: making the backend's json parser work in frontend code (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: making the backend's json parser work in frontend code
|
Список | 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 по дате отправления: