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 | CAKFQuwYhkggPr=6wGGYMMrLmoq+HE29tvw8XXghDUDhSMsi8Nw@mail.gmail.com Whole thread Raw |
| In response to | Re: Add jsonb_compact(...) for whitespace-free jsonb to text (Ryan Pedela <rpedela@datalanche.com>) |
| Responses |
Re: Add jsonb_compact(...) for whitespace-free jsonb to
text
(Alvaro Herrera <alvherre@2ndquadrant.com>)
|
| List | pgsql-hackers |
On Tue, Apr 26, 2016 at 10:49 AM, Stephen Frost <sfrost@snowman.net> wrote:* Ryan Pedela (rpedela@datalanche.com) wrote:
> On Sun, Apr 24, 2016 at 4:02 PM, Sehrope Sarkuni <sehrope@jackdb.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.
pgsql-hackers by date: