Re: Emitting JSON to file using COPY TO - Mailing list pgsql-hackers
From | Andrew Dunstan |
---|---|
Subject | Re: Emitting JSON to file using COPY TO |
Date | |
Msg-id | 22d9e40d-7de2-1301-3970-16136f7732a6@dunslane.net 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
|
List | pgsql-hackers |
On 2023-12-05 Tu 16:02, Joe Conway wrote: > On 12/5/23 15:55, Andrew Dunstan wrote: >> >> On 2023-12-05 Tu 14:50, Davin Shearer wrote: >>> Hi Joe, >>> >>> In reviewing the 005 patch, I think that when used with FORCE ARRAY, >>> we should also _imply_ FORCE ROW DELIMITER. I can't envision a use >>> case where someone would want to use FORCE ARRAY without also using >>> FORCE ROW DELIMITER. I can, however, envision a use case where >>> someone would want FORCE ROW DELIMITER without FORCE ARRAY, like >>> maybe including into a larger array. I definitely appreciate these >>> options and the flexibility that they afford from a user perspective. >>> >>> In the test output, will you also show the different variations with >>> FORCE ARRAY and FORCE ROW DELIMITER => {(false, false), (true, >>> false), (false, true), (true, true)}? Technically you've already >>> shown me the (false, false) case as those are the defaults. >>> >>> >> >> I don't understand the point of FORCE_ROW_DELIMITER at all. There is >> only one legal delimiter of array items in JSON, and that's a comma. >> There's no alternative and it's not optional. So in the array case you >> MUST have commas and in any other case (e.g. LINES) I can't see why you >> would have them. > > The current patch already *does* imply row delimiters in the array > case. It says so here: > 8<--------------------------- > + <varlistentry> > + <term><literal>FORCE_ARRAY</literal></term> > + <listitem> > + <para> > + Force output of array decorations at the beginning and end of > output. > + This option implies the <literal>FORCE_ROW_DELIMITER</literal> > + option. It is allowed only in <command>COPY TO</command>, and > only > + when using <literal>JSON</literal> format. > + The default is <literal>false</literal>. > + </para> > 8<--------------------------- > > and it does so here: > 8<--------------------------- > + if (opts_out->force_array) > + opts_out->force_row_delimiter = true; > 8<--------------------------- > > and it shows that here: > 8<--------------------------- > + copy copytest to stdout (format json, force_array); > + [ > + {"style":"DOS","test":"abc\r\ndef","filler":1} > + ,{"style":"Unix","test":"abc\ndef","filler":2} > + ,{"style":"Mac","test":"abc\rdef","filler":3} > + ,{"style":"esc\\ape","test":"a\\r\\\r\\\n\\nb","filler":4} > + ] > 8<--------------------------- > > It also does not allow explicitly setting row delimiters false while > force_array is true here: > 8<--------------------------- > > + if (opts_out->force_array && > + force_row_delimiter_specified && > + !opts_out->force_row_delimiter) > + ereport(ERROR, > + (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), > + errmsg("cannot specify FORCE_ROW_DELIMITER > false with FORCE_ARRAY true"))); > 8<--------------------------- > > Am I understanding something incorrectly? But what's the point of having it if you're not using FORCE_ARRAY? cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
pgsql-hackers by date: