On 2024-01-17 We 03:52, Laurenz Albe wrote:
On Tue, 2024-01-16 at 11:49 -0500, Andrew Dunstan wrote:
On 2024-01-16 Tu 11:07, Laurenz Albe wrote:
On Tue, 2024-01-09 at 16:51 +0000, Dean Rasheed wrote:
On Tue, 9 Jan 2024 at 14:35, Christoph Berg <m...@debian.org> wrote:
Getting it print numeric/boolean without quotes was actually easy, as
well as json(b). Implemented as the attached v2 patch.
But: not quoting json means that NULL and 'null'::json will both be
rendered as 'null'. That strikes me as a pretty undesirable conflict.
Does the COPY patch also do that?
Yes. Perhaps what needs to happen is for a NULL column to be omitted
entirely from the output. I think the COPY TO json patch would have to
do that if COPY FROM json were to be added later, to make it
round-trip safe.
I think the behavior is fine as it is. I'd expect both NULL and JSON "null"
to be rendered as "null". I think the main use case for a feature like this
is people who need the result in JSON for further processing somewhere else.
"Round-trip safety" is not so important. If you want to move data from
PostgreSQL to PostgreSQL, you use the plain or the binary format.
The CSV format by default renders NULL and empty strings identical, and
I don't think anybody objects to that.
This is absolutely not true.
CSV format with default settings is and has been from the beginning designed
to be round trippable.
Sorry for being unclear. I wasn't talking about COPY, but about the psql
output format:
CREATE TABLE xy (a integer, b text);
INSERT INTO xy VALUES (1, 'one'), (2, NULL), (3, '');
\pset format csv
Output format is csv.
TABLE xy;
a,b
1,one
2,
3,
I think the reason nobody's complained about it is quite possibly that
very few people have used it. That's certainly the case with me - if I'd
noticed it I would have complained.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
