Re: psql JSON output format

From: Christoph Berg <myon(at)debian(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
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 13:42:52
Message-ID: Zkde3HAETD_bJTic@msg.df7cb.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Re: Robert Haas
> IMHO, the big problem here is that different people want different
> corner-case behaviors and it's not clear what to do about that. I
> don't think there's a single vote for "don't do this at all". So if
> there is a desire to take this work forward, the goal probably ought
> to be to try to either (a) figure out one behavior that everyone can
> live with or (b) figure out a short list of options that can be used
> to customize the behavior to a degree that lets everyone get something
> reasonably close to what they want. For instance, "what to do if you
> find a SQL null" and "whether to include json values as strings or
> json objects" seem like they could potentially be customizable. That's
> probably not a silver bullet because (1) that's more work and (2)
> there might be more behaviors than we want to code, or maintain the
> code for, and (3) if it gets too complicated that can itself become a
> source of objections. But it's an idea.

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).

Thoughts?

Christoph

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2024-05-17 13:51:50 Re: psql: Allow editing query results with \gedit
Previous Message Daniel Verite 2024-05-17 13:42:44 Re: First draft of PG 17 release notes