Re: Add partial :-variable expansion to psql \copy - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Add partial :-variable expansion to psql \copy
Date
Msg-id 3881342.1743433798@sss.pgh.pa.us
Whole thread Raw
In response to Add partial :-variable expansion to psql \copy  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: Add partial :-variable expansion to psql \copy
Re: Add partial :-variable expansion to psql \copy
List pgsql-hackers
Fabien COELHO <coelho@cri.ensmp.fr> writes:
> I've been biten by psql's \copy lack of variable expansion, in a limited-access docker-inside-VM context where COPY
isnot a viable option and hardwired names are not desirable. The attached patch allows \copy to use variable's values
inplace of table and file names: 

Hm ... I'm on board with the general idea of the feature, but I find
this implementation quite horrid.  I would rather see us adjust the
lexing rules in psqlscanslash.l so that variable expansion happens
there when collecting \copy arguments.  This would eliminate at
least part of the distinction between OT_WHOLE_LINE and OT_NORMAL
modes, and we'd have to have some discussion about how far to go
there.  Or maybe just change exec_command_copy to use OT_NORMAL
not OT_WHOLE_LINE?  If we modify the behavior of OT_WHOLE_LINE
then the ability to expand variables would start to apply in the
other commands using that, notably \!.  I think that's at least
potentially good, but perhaps the blast radius of such a change
is too large.

Anyway, my feeling about it is that \copy parsing is a huge hack
right now, and I'd rather see it become less of a hack, that is
more like other psql commands, instead of getting even hackier.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Draft for basic NUMA observability
Next
From: Corey Huinker
Date:
Subject: Re: Statistics Import and Export