Re: csv format for psql
От | David G. Johnston |
---|---|
Тема | Re: csv format for psql |
Дата | |
Msg-id | CAKFQuwZtQjSZY9eU_WLh6E7Aa+oTqPCHqZW37m-3iEpOyvy9eQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: csv format for psql ("Daniel Verite" <daniel@manitou-mail.org>) |
Список | pgsql-hackers |
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 по дате отправления: