Re: Add jsonb_compact(...) for whitespace-free jsonb to text

On Thu, Apr 28, 2016 at 10:00 AM, Ryan Pedela <rpedela(at)datalanche(dot)com>
wrote:

> On Tue, Apr 26, 2016 at 10:49 AM, Stephen Frost <sfrost(at)snowman(dot)net>
> wrote:
>
>> * Ryan Pedela (rpedela(at)datalanche(dot)com) wrote:
>> > On Sun, Apr 24, 2016 at 4:02 PM, Sehrope Sarkuni <sehrope(at)jackdb(dot)com>
>> wrote:
>> > > The default text representation of jsonb adds whitespace in between
>> > > key/value pairs (after the colon ":") and after successive properties
>> > > (after the comma ","):
>>
>> [...]
>>
>> > > It'd be nice to have a stable text representation of a jsonb value
>> with
>> > > minimal whitespace. The latter would also save a few bytes per record
>> in
>> > > text output formats, on the wire, and in backups (ex: COPY ... TO
>> STDOUT).
>> >
>> > +1
>> >
>> > I cannot comment on the patch itself, but I welcome jsonb_compact() or
>> some
>> > way to get JSON with no inserted whitespace.
>>
>> As I mentioned to Sehrope on IRC, at least for my 2c, if you want a
>> compact JSON format to reduce the amount of traffic over the wire or to
>> do things with on the client side, we should probably come up with a
>> binary format, rather than just hack out the whitespace. It's not like
>> representing numbers using ASCII characters is terribly efficient
>> either.
>
>
> Why build a Ferrari when a skateboard would suffice? Besides, that doesn't
> help one of the most common cases for JSONB: REST APIs.
>

​I'm agreeing with this sentiment. This isn't an either-or situation so
argue the white-space removal on its own merits. The fact that we might
implement a binary representation in the future doesn't, for me, influence
whether we make this white-space change now.
​

>
> Now that PG fully supports JSON, a user can use PG to construct the JSON
> payload of a REST API request. Then the web server would simply be a
> pass-through for the JSON payload. I personally have this use case, it is
> not hypothetical.
>
However currently, a user must parse the JSON string from PG and
> re-stringify it to minimize the whitespace. Given that HTTP is text-based,
> removing all extraneous whitespace is the best way to compress it, and on
> top of that you can do gzip compression.
>

Can you clarify what you mean by "and on top of that you can do gzip
compression"?​​

Unless you are suggesting that the binary format is just a gzipped version
> of the minimized text format, I don't see how a binary format helps at all
> in the REST API case.
>
>
No, I'm pretty sure you still end up with uncompressed text in the
application layer.​

> In addition, every JSON implementation I have ever seen fully minimizes
> JSON by default. PG appears to deviate from standard practice for no
> apparent reason.
>

Sorry to nit-pick but that's called convention - the standard is likely
silent on this point. And its not like this was done in a vacuum - why is
this only coming up now and not, say, during the beta? Is it surprising
that this seemingly easy-to-overlook dynamic was not explicitly addressed
by the author and reviewer of the patch, especially when implementation of
said feature consisted of a lot more things of greater import and impact?

David J.