pá 17. 5. 2024 v 16:04 odesílatel Robert Haas <robertmh...@gmail.com>
napsal:
> On Fri, May 17, 2024 at 9:42 AM Christoph Berg <m...@debian.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
>
>
>
