From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Christoph Berg <myon(at)debian(dot)org>, 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:14:02 |
Message-ID: | CAFj8pRDecv1bURtWj67k1DLCy6O9Efw4BdakotXAqtw37DjMPQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
pá 17. 5. 2024 v 16:04 odesílatel Robert Haas <robertmhaas(at)gmail(dot)com>
napsal:
> 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?
>
+1 for separate options
lot of these proposed options can be used for XML too
Regards
Pavel
> --
> Robert Haas
> EDB: http://www.enterprisedb.com
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2024-05-17 14:15:31 | Re: commitfest.postgresql.org is no longer fit for purpose |
Previous Message | Robert Haas | 2024-05-17 14:10:05 | Re: commitfest.postgresql.org is no longer fit for purpose |