From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Daniel Verite <daniel(at)manitou-mail(dot)org> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, David Steele <david(at)pgmasters(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: csv format for psql |
Date: | 2018-03-26 19:51:25 |
Message-ID: | CAFj8pRABGk+8OUmBhfdXwgzi0SYGyF6O87-aEGod4DdwuDnrSw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2018-03-26 20:26 GMT+02:00 Daniel Verite <daniel(at)manitou-mail(dot)org>:
> Pavel Stehule wrote:
>
> > b) the list of pset options is bloating - every possible new format can
> > introduce fieldsep_X option
>
> What new format?
> The usefulness of fieldsep does not extend outside of xSV, and it's
> no suprise that there have been no other use for a fieldsep-like
> variable until now, with the other formats supported in psql.
>
I can imagine format based on \t as field separator, or some other
invisible chars.
>
> In fact it's even absurd for any format to use a non-fixed separator
> at a place that is key for being parsed unambiguously.
>
> We could even support only the comma and make it non-configurable
> based on the fact it's Comma-Separated-Values, not
> Whatever-Separated-Values, except that won't do much
> to serve the users interests, as the reality is that
> people use various separators.
>
I don't think so allow only comma as separator is the solution.
Regards
Pavel
>
>
> Best regards,
> --
> Daniel Vérité
> PostgreSQL-powered mailer: http://www.manitou-mail.org
> Twitter: @DanielVerite
>
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2018-03-26 19:57:19 | Re: WIP: Covering + unique indexes. |
Previous Message | Peter Eisentraut | 2018-03-26 19:46:40 | Re: committing inside cursor loop |