Re: JSON output from psql

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: Gurjeet Singh <gurjeet(at)singh(dot)im>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: JSON output from psql
Date: 2020-05-13 21:01:18
Message-ID: 5EBC601E.3020704@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 05/13/20 16:16, Gurjeet Singh wrote:
> On Wed, May 13, 2020 at 1:14 PM Gurjeet Singh <gurjeet(at)singh(dot)im> wrote:
>>
>> Arguably, delivering JSON (with its repeating attribute names in every
>> element of the array, dquotes and commas) is more network intensive
>> than converting the resultset to JSON on [client] side.

Does this suggest perhaps some sort of hybrid approach, where jsonbc
could be available as a binary on-the-wire format and the client only
needs the ability to deparse it: a query on the server could marshal
the results into that form, the client negotiates the binary transfer
format, and deparses to normal JSON syntax on its end?

It seems the server-side "compression" to jsonbc should be optimizable
when what is happening is marshaling of a tabular result: what the
repeating keys are going to be is known up front.

Maybe could use a transient (or session lifetime?) 'external' dictionary
that gets generated and sent to the client. but not stored in
pg_jsonb_dict?

Seems like a lot of work just to get json-shaped query results from psql,
but maybe the ability to receive jsonbc on the wire would be of interest
to drivers generally.

Regards,
-Chap

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2020-05-13 21:17:42 document? Re: Do I understand commit timestamps correctly?
Previous Message Laurenz Albe 2020-05-13 20:36:40 Re: COPY, lock release and MVCC