From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Christoph Berg <myon(at)debian(dot)org> |
Cc: | 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-01-16 16:07:36 |
Message-ID: | 86b3f864d7578df5a20b5c9db12bc62346afa1e0.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2024-01-09 at 16:51 +0000, Dean Rasheed wrote:
> On Tue, 9 Jan 2024 at 14:35, Christoph Berg <myon(at)debian(dot)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.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2024-01-16 16:07:48 | Re: introduce dynamic shared memory registry |
Previous Message | Konstantin Knizhnik | 2024-01-16 16:07:16 | Re: Custom explain options |