| From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> | 
|---|---|
| To: | "Fabien COELHO" <coelho(at)cri(dot)ensmp(dot)fr> | 
| Cc: | "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: csv format for psql | 
| Date: | 2018-08-28 16:45:25 | 
| Message-ID: | 6306a434-555c-47c7-a125-3b174daadb2a@manitou-mail.org | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Fabien COELHO wrote:
> My point was more about the documentation which should be clear about what 
> is the EOL. I understand from your point above that the EOL is the 
> platform-specific one, which is yet again fine with me, but should be said 
> clearly in the documentation?
Okay, I've added a bit in the doc.
>   + else if (strcmp(param, "fieldsep_csv") == 0)
>   +     return pset_quoted_string(popt->topt.fieldSepCsv
>   +                               ? popt->topt.fieldSepCsv
>   +                               : "");
> 
> It is unclear to me when this "" is triggered. Never? If so, maybe a 
> comment should say so?
Currently popt->topt.fieldSepCsv can't be NULL so I've simplified this
to just return pset_quoted_string(popt->topt.fieldSepCsv).
> Why removing "-C"? As we already have "-A" an "-H", I was fine with it.
It was a leftover from v3. Participants in the thread don't seem to
want the short option, to my surprise. Pavel argued first against -C
upthread, I argued quite a bit in favor of it, the "for" had 0 upvote, and
"against" had at least 4 I think, including yours in [1].
> It seems that you changed the indentation in "psql-ref.sgml":
> 
>        </varlistentry>
>   -    <varlistentry>
>   +     <varlistentry>
Fixed.
>   -  {"unaligned", "aligned", "wrapped", "html", "asciidoc",
>   -   "latex", "latex-longtable", "troff-ms", NULL};
>   +  {"aligned", "asciidoc", "csv", "html", "latex", "latex-longtable",
>   +   "unaligned", "troff-ms", "wrapped", NULL};
> 
> If you want alphabetical, 'u' > 't'.
Fixed.
> 
> While testing I found a small issue if "fieldsep_csv" is set to a strange 
> value:
> 
>    \pset format_csv ',,'
>    SELECT ',', ',';
>    -- gives the ambiguous:
>    ,,,,
> 
> The rule to decide whether to quote should be made safer/smarter. I'd 
> suggest that if the string contains any of the caracters used in format 
> csv it should be quoted.
You meant \pset fieldsep_csv ',,'
If you do that even SELECT 'foo', 'bar' comes out wrong because it looks
like a 3-field row: foo,,bar
If we want to prevent people to shoot themselves in the foot with that
sort of thing, I've added a couple tests: No double quote, no LF or
CR, single character (but multibyte allowed) for the separator.
[1]
https://www.postgresql.org/message-id/alpine.DEB.2.20.1803081004241.2916%40lancre
Best regards,
-- 
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
Best regards,
-- 
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
| Attachment | Content-Type | Size | 
|---|---|---|
| psql-csv-format-v7.patch | text/plain | 20.1 KB | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2018-08-28 17:08:35 | Re: Would it be possible to have parallel archiving? | 
| Previous Message | Christoph Berg | 2018-08-28 16:38:58 | Re: logical decoding: ABI break in 10.5 et al |