Re: Emitting JSON to file using COPY TO

Andrew Dunstan <andrew@dunslane.net>

From: Andrew Dunstan <andrew@dunslane.net>
To: "David G. Johnston" <david.g.johnston@gmail.com>, Joe Conway <mail@joeconway.com>
Cc: Sehrope Sarkuni <sehrope@jackdb.com>, Tom Lane <tgl@sss.pgh.pa.us>, Davin Shearer <davin@apache.org>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2023-12-07T13:19:19Z
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 →
  1. Add option force_array for COPY JSON FORMAT

  2. json format for COPY TO

  3. introduce CopyFormat, refactor CopyFormatOptions

  4. Doc: add IDs to copy.sgml's <varlistentry> and <refsect1>

On 2023-12-06 We 17:56, David G. Johnston wrote:
> On Wed, Dec 6, 2023 at 3:38 PM Joe Conway <mail@joeconway.com> wrote:
>
>     So the questions are:
>     1. Do those two formats work for the initial implementation?
>
>
> Yes.  We provide a stream-oriented format and one atomic-import format.
>
>     2. Is the default correct or should it be switched
>         e.g. rather than specifying FORCE_ARRAY to get an
>         array, something like FORCE_NO_ARRAY to get JSON lines
>         and the JSON array is default?
>
>
> No default?
>
> Require explicit of a sub-format when the main format is JSON.
>
> JSON_OBJECT_ROWS
> JSON_ARRAY_OF_OBJECTS
>
> For a future compact array-structured-composites sub-format:
> JSON_ARRAY_OF_ARRAYS
> JSON_ARRAY_ROWS
>
>

No default seems unlike the way we treat other COPY options. I'm not 
terribly fussed about which format to have as the default, but I think 
we should have one.


cheers


andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com