On Thu, Apr 28, 2016 at 10:00 AM, Ryan Pedela <rped...@datalanche.com> wrote:
> On Tue, Apr 26, 2016 at 10:49 AM, Stephen Frost <sfr...@snowman.net> > wrote: > >> * Ryan Pedela (rped...@datalanche.com) wrote: >> > On Sun, Apr 24, 2016 at 4:02 PM, Sehrope Sarkuni <sehr...@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.
