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
