Re: Add jsonb_compact(...) for whitespace-free jsonb to text - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Add jsonb_compact(...) for whitespace-free jsonb to text
Date
Msg-id CAKFQuwbXf4UfYFC_6OfpjYnMomedSOknZtpx7m10CijVnuqZfA@mail.gmail.com
Whole thread Raw
In response to Add jsonb_compact(...) for whitespace-free jsonb to text  (Sehrope Sarkuni <sehrope@jackdb.com>)
Responses Re: Add jsonb_compact(...) for whitespace-free jsonb to text  (Sehrope Sarkuni <sehrope@jackdb.com>)
List pgsql-hackers
On Sun, Apr 24, 2016 at 3:02 PM, Sehrope Sarkuni <sehrope@jackdb.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.

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

​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.

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.

David J.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Modify the isolation tester so that multiple sessions can wait.
Next
From:
Date:
Subject: Shared memory and processes