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

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Sehrope Sarkuni <sehrope(at)jackdb(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add jsonb_compact(...) for whitespace-free jsonb to text
Date: 2016-04-27 23:09:53
Message-ID: CAKFQuwbXf4UfYFC_6OfpjYnMomedSOknZtpx7m10CijVnuqZfA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message david 2016-04-28 00:56:51 Shared memory and processes
Previous Message Andres Freund 2016-04-27 23:05:16 Re: Getting Citus into (Debian) PGDG