From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Daniel Verite <daniel(at)manitou-mail(dot)org>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: csv format for psql |
Date: | 2018-11-12 04:18:39 |
Message-ID: | CAKFQuwYbCdrxTey7L_0_W1bDVLSBtsWwCPsepOqMzD5R29nr7w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Friday, November 9, 2018, Michael Paquier <michael(at)paquier(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Imai, Yoshikazu | 2018-11-12 04:35:30 | RE: speeding up planning with partitions |
Previous Message | Amit Langote | 2018-11-12 04:17:35 | Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation |