Re: Alternative to \copy in psql modelled after \g - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Alternative to \copy in psql modelled after \g
Date
Msg-id alpine.DEB.2.21.1812261415451.32444@lancre
Whole thread Raw
In response to Re: Alternative to \copy in psql modelled after \g  ("Daniel Verite" <daniel@manitou-mail.org>)
Responses Re: Alternative to \copy in psql modelled after \g
List 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.


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Feature: triggers on materialized views
Next
From: Alexey Kondratov
Date:
Subject: Re: [Patch] pg_rewind: options to use restore_command fromrecovery.conf or command line