From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Daniel Verite <daniel(at)manitou-mail(dot)org> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Subject: | Re: Alternative to \copy in psql modelled after \g |
Date: | 2018-12-26 13:37:51 |
Message-ID: | alpine.DEB.2.21.1812261415451.32444@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
>> Is this just kind of a bug fix? Beforehand the documentation says "\g fn"
>> sends to file, but that was not happening with COPY, and now it does as it
>> says?
>
> Yes. [...]
>
> It does not add "unless the query is a COPY", so it seems right
> to make that just work, and call it a bug fix.
Does this suggest backpatching?
>> However, it does not contain any tests (bad:-)
>
> Testing this requires at least some interaction with the OS which I'm
> uncomfortable to add.
Hmmm. This means that "\g filename" goes fully untested:-( A casual grep
seems to confirm this. Sigh:-(
> There is a precedent in regress/sql/hs_standby_allowed.sql doing:
>
> COPY hs1 TO '/tmp/copy_test'
> \! cat /tmp/copy_test
Indeed. I'm unsure windows has cat or /tmp, so I do not understand how it
works on such platform. Maybe I'm missing something.
> We could add something like that in psql.sql, but I'm not fond of it
> because it assumes a Unix-ish environment,
Yep.
> I'm open to ideas on a portable way for psql.sql to test \g writing to a
> file or a program, but ATM my inclination is to not add that test.
A relative file could be ok? After some testing, the standard regression
tests do not cd to some special place, so it may fail?
However TAP tests do that, and I have used this extensively with pgbench,
so a psql TAP test could do that and other things, such as importing a csv
file or whatever.
>> nor documentation (hmmm... maybe none needed, though).
>
> \copy has this paragraph:
>
> "The syntax of this command is similar to that of the SQL COPY
> command. All options other than the data source/destination are as
> specified for COPY. Because of this, special parsing rules apply to
> the \copy meta-command. Unlike most other meta-commands, the entire
> remainder of the line is always taken to be the arguments of \copy,
> and neither variable interpolation nor backquote expansion are
> performed in the arguments".
>
> We could add that COPY TO STDOUT with a redirection might be used as an
> alternative. The downside is that with four paragraphs plus one tip,
> the explanations on \copy give already a lot to chew on, so is it
> worth to add more?
I'd say that a small paragraph with the tip would be ok.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Alexey Kondratov | 2018-12-26 14:11:34 | Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line |
Previous Message | Alvaro Herrera | 2018-12-26 12:38:56 | Re: Feature: triggers on materialized views |