Re: psql JSON output format

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Christoph Berg <myon(at)debian(dot)org>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Stefan Keller <sfkeller(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Joe Conway <mail(at)joeconway(dot)com>
Subject: Re: psql JSON output format
Date: 2024-05-17 14:04:31
Message-ID: CA+TgmoYwzCU5t9dt6Y7nLQgQ+cJejUrCp4=iD+K3Cai4CBWSMQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 17, 2024 at 9:42 AM Christoph Berg <myon(at)debian(dot)org> wrote:
> Thanks for summarizing the thread.
>
> Things mentioned in the thread:
>
> 1) rendering of SQL NULLs - include or omit the column
>
> 2) rendering of JSON values - both "quoted string" and "inline as
> JSON" make sense
>
> 3) not quoting numeric values and booleans
>
> 4) no special treatment of other datatypes like arrays or compound
> values, just quote them
>
> 5) row format: JSON object or array (array would be close to CSV
> format)
>
> 6) overall format: array of rows, or simply print each row separately
> ("JSON Lines" format, https://jsonlines.org/)
>
> I think 1, 2 and perhaps 6 make sense to have configurable. Two or
> three \pset options (or one option with a list of flags) don't sound
> too bad complexity-wise.
>
> Or maybe just default to "omit NULL columns" and "inline JSON" (and
> render null as NULL).

If we're going to just have one option, I agree with making that the
default, and I'd default to an array of row objects. If we're going to
have something configurable, I'd at least consider making (4)
configurable.

It's tempting to just have one option, like \pset jsonformat
nullcolumns=omit;inlinevalues=json,array;rowformat=object;resultcontainer=array
simply because adding a ton of new options just for this isn't very
appealing. But looking at how long that is, it's probably not a great
idea. So I guess separate options is probably better?

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2024-05-17 14:10:05 Re: commitfest.postgresql.org is no longer fit for purpose
Previous Message Joe Conway 2024-05-17 13:54:08 Re: commitfest.postgresql.org is no longer fit for purpose