Re: [HACKERS] bytea_output output of base64
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] bytea_output output of base64 |
Дата | |
Msg-id | 20170224022252.GA8432@momjian.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] bytea_output output of base64 (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] bytea_output output of base64
|
Список | pgsql-hackers |
On Thu, Feb 23, 2017 at 07:09:57PM -0500, Andrew Dunstan wrote: > > > On 02/23/2017 06:52 PM, David Fetter wrote: > > On Thu, Feb 23, 2017 at 05:55:37PM -0500, Bruce Momjian wrote: > >> On Thu, Feb 23, 2017 at 04:08:58PM -0500, Tom Lane wrote: > >>> Bruce Momjian <bruce@momjian.us> writes: > >>>> Is there a reason we don't support base64 as a bytea_output output > >>>> option, except that no one has implemented it? > >>> How about "we already have one too many bytea output formats"? > >>> I don't think forcing code to try to support still another one > >>> is a great thing ... especially not if it couldn't be reliably > >>> distinguished from the hex format. > >> Is there a reason we chose hex over base64? > > Whether there was or not, there's not a compelling reason now to break > > people's software. When people want compression, methods a LOT more > > effective than base64 are common. Gzip, for example. > > > > > What's the use case anyway? It's already supported by the encode() and > decode() functions if you need that format. I was just curious because it seems more compact than hex and many exchange formats use it, like SSL certificates and keys. I know you can encode() but I thought it might help make pg_dump output smaller. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
В списке pgsql-hackers по дате отправления: