Re: csv format for psql

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: csv format for psql
Дата
Msg-id 20181109234414.GA2071@paquier.xyz
обсуждение исходный текст
Ответ на Re: csv format for psql  ("Daniel Verite" <daniel@manitou-mail.org>)
Ответы Re: csv format for psql  ("Daniel Verite" <daniel@manitou-mail.org>)
Re: csv format for psql  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: csv format for psql  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-hackers
On Fri, Nov 09, 2018 at 05:28:07PM +0100, Daniel Verite wrote:
> But again COPY is concerned with importing the data that preexists,
> even if it's weird, whereas a psql output formats are not.

Hm.  I checked the contents of the patch in details which provide output
consistent with COPY, but after looking at the global picture I am
getting cold feet on this patch for a couple of reasons:
- This stuff adds new code paths in the frontend mimicking what the
backend already does for years, both doing the same thing.
- There are already three ways to fetch data in this format with COPY,
\copy and file_fdw, with all three using the same code paths for option
validations (I can see the arguments at the top of the thread for which
COPY SELECT can actually do everything you want with?).
- The experience is confusing, as the psql format uses different options
than the backend to do the same things:
-- tuples_only instead of HEADER.
-- fieldsep_csv instead of DELIMITER
-- null is an equivalent of the one with the same name, which is
actually consistent.
-- encoding is also an equivalent of ENCODING.
-- and all the others missing.
That looks like a lot.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Make description of heap records more talkative for flags