Re: [PATCH] Generalized JSON output functions - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [PATCH] Generalized JSON output functions
Date
Msg-id CAFj8pRAcOk8C6DG2bV68P1AZJr7BcurQz_sUu=4uh0LyZk5fyw@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Generalized JSON output functions  ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>)
Responses Re: [PATCH] Generalized JSON output functions
List 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 by date:

Previous
From: Shay Rojansky
Date:
Subject: Making ParameterStatus available for more parameter types?
Next
From: Yourfriend
Date:
Subject: Could be improved point of UPSERT