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
