Re: Emitting JSON to file using COPY TO - Mailing list pgsql-hackers

From Daniel Verite
Subject Re: Emitting JSON to file using COPY TO
Date
Msg-id 3df907b2-0a3a-4597-8ef1-707b553667cd@manitou-mail.org
Whole thread Raw
In response to Re: Emitting JSON to file using COPY TO  (Joe Conway <mail@joeconway.com>)
Responses Re: Emitting JSON to file using COPY TO
Re: Emitting JSON to file using COPY TO
List pgsql-hackers
    Joe Conway wrote:

> The attached should fix the CopyOut response to say one column. I.e. it
> ought to look something like:

Spending more time with the doc I came to the opinion that in this bit
of the protocol, in CopyOutResponse (B)
...
Int16
The number of columns in the data to be copied (denoted N below).
...

this number must be the number of columns in the source.
That is for COPY table(a,b,c)    the number is 3, independently
on whether the result is formatted in text, cvs, json or binary.

I think that changing it for json can reasonably be interpreted
as a protocol break and we should not do it.

The fact that this value does not help parsing the CopyData
messages that come next is not a new issue. A reader that
doesn't know the field separator and whether it's text or csv
cannot parse these messages into fields anyway.
But just knowing how much columns there are in the original
data might be useful by itself and we don't want to break that.


The other question for me is, in the CopyData message, this
bit:
" Messages sent from the backend will always correspond to single data rows"

ISTM that considering that the "[" starting the json array is a
"data row" is a stretch.
That might be interpreted as a protocol break, depending
on how strict the interpretation is.



Best regards,
--
Daniel Vérité
https://postgresql.verite.pro/
Twitter: @DanielVerite



pgsql-hackers by date:

Previous
From: Jeevan Chalke
Date:
Subject: Re: More new SQL/JSON item methods
Next
From: Sacha Hottinger
Date:
Subject: AW: Building PosgresSQL with LLVM fails on Solaris 11.4