Re: additional json functionality

Поиск
Список
Период
Сортировка
От Gavin Flower
Тема Re: additional json functionality
Дата
Msg-id 528BB330.7060405@archidevsys.co.nz
обсуждение исходный текст
Ответ на Re: additional json functionality  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: additional json functionality  (David Johnston <polobo@yahoo.com>)
Список pgsql-hackers
On 20/11/13 05:14, Robert Haas wrote:
> On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing <hannu@2ndquadrant.com> wrote:
>> I am sure you could also devise an json encoding scheme
>> where white space is significant ;)
> I don't even have to think hard.  If you want your JSON to be
> human-readable, it's entirely possible that you want it stored using
> the same whitespace that was present on input.  There is a valid use
> case for normalizing whitespace, too, of course.
>
> Everyone on this thread who thinks that there is Only One Right Way To
> Do It should take a chill pill.  There is, in fact, more than one
> right way to do it.
>
There is only one obvious 'Right Way', and that is 'My Way'!  :-)

More seriously, there are obviously variants in what people consider 
useful human readable form of JSON output, but it is probably 
inefficient to store white space.  Which suggests it might be useful to 
allow users to store rules so that the output and include the white 
space that they want.  However, this is non-trivial - for example 
Eclipse allows Java/XML source to be formatted in different ways (here 
the source files are store with white space), but lacks a couple of 
options that I would like.  Possibly, JSON output of white space would 
be less problematical?


Cheers,
Gavin



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1
Следующее
От: Andrew Gierth
Дата:
Сообщение: Re: UNNEST with multiple args, and TABLE with multiple funcs