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

On Wed, Apr 27, 2016 at 7:09 PM, David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Sun, Apr 24, 2016 at 3:02 PM, Sehrope Sarkuni <sehrope(at)jackdb(dot)com>
> wrote:
>
>> Attached is a *very* work in progress patch that adds a
>> jsonb_compact(jsonb)::text function. It generates a text representation
>> without extra whitespace but does not yet try to enforce a stable order of
>> the properties within a jsonb value.
>>
>
> ​I think that having a jsonb_compact function that complements the
> existing jsonb_pretty function is a well scoped and acceptable​ feature. I
> do not believe that it should also take on the role of canonicalization.
>
> I'd suggest that any discussions regarding stability of jsonb output be
> given its own thread.
>

I'm fine with removing the stability aspect. I think it's nice-to-have but
it definitely complicates things and has longer term consequences.

> That topic also seems separate from a discussion on how to implement a
> binary transport protocol for jsonb.
>

Defining a binary format for jsonb is definitely out of scope.

> ​Lastly would be whether we change our default text representation so that
> users utilizing COPY get the added benefit of a maximally minimized text
> representation.
>

I see this applying to both COPY and the text format on the wire. The
latter has the added benefit that it works with existing clients without
any driver changes.

Outside of being a bit more pleasant in psql, I don't see a point in the
added whitespace for jsonb::text. Even in psql it only helps with small
fields as anything big isn't really legible without indenting it via
jsonb_pretty(...).

> As an aside on the last topic, has there ever been considered to have a
> way to specify a serialization function to use for a given type (or maybe
> column) specified in a copy command?
>
> Something like: COPY [...] WITH (jsonb USING jsonb_compact)
>
> I'm thinking this would hard and undesirable given the role copy plays and
> limited intelligence that it has in order to maximize its efficiency in
> fulfilling its role.
>
> Backups get compressed already so bandwidth seems the bigger goal there.
> Otherwise I'd say that we lack any kind of overwhelming evidence that
> making such a change would be warranted.
>
> While these are definitely related topics it doesn't seem like any are
> pre-requisites for the others. I think this thread is going to become hard
> to follow and trail off it continues to try and address all of these topics
> randomly as people see fit to reply. And it will quickly become hard for
> anyone to jump in and understand the topics at hand.
>

That's a really cool idea but agree it's way out of scope for this.

I had a related idea, maybe something similar could be done for psql to set
a jsonb output format. That way you could automatically prettify jsonb
fields client side.

Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/