Re: [PATCH] Generalized JSON output functions

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [PATCH] Generalized JSON output functions
Дата
Msg-id CAFj8pRAcOk8C6DG2bV68P1AZJr7BcurQz_sUu=4uh0LyZk5fyw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Generalized JSON output functions  ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>)
Ответы Re: [PATCH] Generalized JSON output functions  (Merlin Moncure <mmoncure@gmail.com>)
Список pgsql-hackers


2015-07-12 10:29 GMT+02:00 Shulgin, Oleksandr <oleksandr.shulgin@zalando.de>:

On Jul 11, 2015 8:41 PM, "Pavel Stehule" <pavel.stehule@gmail.com> wrote:
>
> There is simple rule - be strict on output and tolerant on input. If I understand to sense of this patch - the target is one same format of JSON documents - so there are no space for any variability.

So, would you prefer explain json format on a single line - no indentation or whitespace whatsoever?

yes, - if you need pretty format - there is function json_pretty - any more styles is wrong on Postgres side.
 

This far it was only about whitespace, but it can be useful for tweaking other aspects of output, as I've mentioned before.

Postgres is database, not presentation server - it have to to any database operations, quickly as possible - and formatting is part of client side.

I can imagine the ability for 3rd-party code to override certain aspects of the output would be really useful for extensions or background workers, decoding plugins, etc.

we talking about output - I can imagine, so there is only two possibilities - plain join, and pretty formatted join (but with only one style).

 

> I am thinking so general json functions has sense, but I partially disagree with your implementation.

Then what would you differently exactly?

simple code.

 

--
Alex


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

Предыдущее
От: Shay Rojansky
Дата:
Сообщение: Making ParameterStatus available for more parameter types?
Следующее
От: Yourfriend
Дата:
Сообщение: Could be improved point of UPSERT