Re: csv format for psql

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: csv format for psql
Дата
Msg-id CAKFQuwYbCdrxTey7L_0_W1bDVLSBtsWwCPsepOqMzD5R29nr7w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: csv format for psql  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: csv format for psql  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
On Friday, November 9, 2018, Michael Paquier <michael@paquier.xyz> wrote:
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.

From the original post:

"copy with csv can't help for the output of meta-commands
such as \gx, \crosstabview, \l, \d ... whereas a CSV format within psql
does work with these."

Formatting is usually a client-side concern so this feature fits well there. The fact that we’ve provided a server interface for the same doesn’t preclude its potential desirability in the client.

- 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?).

Not always conveniently.
 
- The experience is confusing, as the psql format uses different options
than the backend to do the same things:

Yes, those who use psql need to learn its features.  I’d posit that since this syntax is being learned anyway that transferring said knowledge to a newly added csv format will not be confusing.  No more so that having to do something that is usually client-side (formatting) on the server in the first place.  That we don’t fully replicate the server functionality does’t bother be.  This is meant to be a simple and quick ability that handles 95% of use cases and defers to the more powerful server version for the outliers.

Feature-wise I’m on board.  Given it’s already written I’d say it should go in unless there are code complexity and support concerns - which given the prevalence of other formats I have to believe there are not.

David J.

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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: BUG #15212: Default values in partition tables don't work asexpected and allow NOT NULL violation
Следующее
От: "Imai, Yoshikazu"
Дата:
Сообщение: RE: speeding up planning with partitions