Re: Emitting JSON to file using COPY TO - Mailing list pgsql-hackers
From | Joe Conway |
---|---|
Subject | Re: Emitting JSON to file using COPY TO |
Date | |
Msg-id | 86650b9d-ff52-4ec8-964d-4b9352971ecd@joeconway.com Whole thread Raw |
In response to | Re: Emitting JSON to file using COPY TO (Andrew Dunstan <andrew@dunslane.net>) |
List | pgsql-hackers |
On 12/5/23 16:12, Andrew Dunstan wrote: > > 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? See the follow up email -- other databases support it so why not? It seems to be a thing... -- Joe Conway PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
pgsql-hackers by date: