Re: csv format for psql - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: csv format for psql
Date
Msg-id CAKFQuwZtQjSZY9eU_WLh6E7Aa+oTqPCHqZW37m-3iEpOyvy9eQ@mail.gmail.com
Whole thread Raw
In response to Re: csv format for psql  ("Daniel Verite" <daniel@manitou-mail.org>)
List pgsql-hackers
On Fri, Mar 9, 2018 at 3:18 PM, Daniel Verite <daniel@manitou-mail.org> wrote:
I think that the point of recordsep in unaligned mode is you can set it
to something that never appears in the data, especially when embedded
newlines might be in the data. In CSV this is solved differently so
we don't need it.

​I'd rather argue it from the standpoint that \copy doesn't use recordsep nor fieldsep and thus neither should --csv; which is arguably a convenience invocation of \copy that pipes to psql's stdout (and overcomes \copy's single-line limitation - which I think still exists... - and inability to use variables - does it?...).  COPY doesn't allow for changing the record separator and the newline output is system-dependent.  I can accept the same limitation with this feature.

I suppose the question is how many "COPY" options do we want to expose on the command line, and how does it look?

I'll put a -1 on having a short option (-C or otherwise); "that is the way its always been done" doesn't work for me here - by way of example "-a and -A" is ill-advised; --echo-all does not seem important enough to warrant a short option (especially not a lower-case one) and so the more useful unaligned mode is forced into the secondary capital A position.

David J.

pgsql-hackers by date:

Previous
From: Yura Sokolov
Date:
Subject: Re: [HACKERS] Lazy hash table for XidInMVCCSnapshot (helps Zipfian abit)
Next
From: Tom Lane
Date:
Subject: Re: constraint exclusion and nulls in IN (..) clause