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

From Shulgin, Oleksandr
Subject Re: [PATCH] Generalized JSON output functions
Date
Msg-id CACACo5RwrnmU1djhLgVv_PhHHJ-j4K0qsppdshFDCA5a33Az+g@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Generalized JSON output functions  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: [PATCH] Generalized JSON output functions  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
<p dir="ltr">On Jul 11, 2015 8:41 PM, "Pavel Stehule" <<a
href="mailto:pavel.stehule@gmail.com">pavel.stehule@gmail.com</a>>wrote:<br /> ><br /> > 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
JSONdocuments - so there are no space for any variability.<p dir="ltr">So, would you prefer explain json format on a
singleline - no indentation or whitespace whatsoever?<p dir="ltr">This far it was only about whitespace, but it can be
usefulfor tweaking other aspects of output, as I've mentioned before.<p dir="ltr">I can imagine the ability for
3rd-partycode to override certain aspects of the output would be really useful for extensions or background workers,
decodingplugins, etc.<p dir="ltr">> I am thinking so general json functions has sense, but I partially disagree with
yourimplementation.<p dir="ltr">Then what would you differently exactly?<p dir="ltr">--<br /> Alex 

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Next
From: Yaroslav
Date:
Subject: A little RLS oversight?