Re: [PATCH] Generalized JSON output functions
От | Merlin Moncure |
---|---|
Тема | Re: [PATCH] Generalized JSON output functions |
Дата | |
Msg-id | CAHyXU0xq0a0RazxR3dCmBD1GKDueOXTzW-C4ihMkp9-zQF8PXQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Generalized JSON output functions (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: [PATCH] Generalized JSON output functions
|
Список | pgsql-hackers |
On Sun, Jul 12, 2015 at 4:35 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote: > > > 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). This makes sense. Postgres core really only needs to support the minimum styles necessary for core requirements. This means raw unformatted json for data productions to client and an appropriate formatting for explain. Fancier stuff like a generic formatted is fine but those features *belong in an extension*. merlin
В списке pgsql-hackers по дате отправления: