Re: Alternative to \copy in psql modelled after \g

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.

In response to

Responses

Browse pgsql-hackers by date

  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