Re: Emitting JSON to file using COPY TO
Daniel Verite <daniel@manitou-mail.org>
From: "Daniel Verite" <daniel@manitou-mail.org>
To: "Joe Conway" <mail@joeconway.com>
Cc: Andrew Dunstan <andrew@dunslane.net>,
Davin Shearer <davin@apache.org>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2023-12-07T13:35:52Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add option force_array for COPY JSON FORMAT
- 4c0390ac53b7 19 (unreleased) landed
-
json format for COPY TO
- 7dadd38cda95 19 (unreleased) landed
-
introduce CopyFormat, refactor CopyFormatOptions
- a2145605ee3d 19 (unreleased) landed
-
Doc: add IDs to copy.sgml's <varlistentry> and <refsect1>
- e4018f891dec 19 (unreleased) cited
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