|From:||Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>|
|To:||Michael Paquier <michael(at)paquier(dot)xyz>|
|Cc:||Daniel Verite <daniel(at)manitou-mail(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: csv format for psql|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
>> 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.
- Backend's COPY cannot write to client space, so the comparison
is not relevant.
- "\copy (SQL-query) TO STDOUT CSV;" is kind of a pain, because one has
to edit around the query, which is not convenient, esp from the
sh> psql --csv -c 'SELECT 1 as one, 2 as two' > out.csv
sh> psql -c "\copy (SELECT 1 AS one, 2 as two) TO STDOUT CSV" > out.csv
or mixing the output file name inside the argument, which is very
sh> psql -c "\copy (SELECT 1 AS one, 2 as two) TO 'out.csv' CSV"
If you have a "query.sql" file that you want to output in csv, there is no
simple way to do that with \copy/COPY, whereas "psql --csv -f query.sql"
looks pretty straightforward to me. Also, in a makefile, I could write:
psql --csv -f $< > $@
My point is that \copy, COPY and the proposed CSV format do not address
the same use cases.
> - 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.
I disagree on this one: the proposed csv format just follows the existing
psql format pattern used for 8 formats and reuses it for csv.
Note that there are existing command line options for tuples_only (-t),
encoding is inherited from the shell and does not need to be changed that
often nowadays, fieldsep_csv is kind-of a pain, but then if someone wants
"comma-separated-values" NOT separated by commas, probably they can handle
Basically the proposed patch addresses a simple and convenient use case
which are neither addressed by \copy nor COPY. The fact that more options
are available with these commands does it precludes its usefulness as is.
|Next Message||Raúl Marín Rodríguez||2018-11-14 12:46:34||[PATCH] Memory leak in pg_config|
|Previous Message||Joshua Yanovski||2018-11-14 11:52:27||Re: In-place updates and serializable transactions|