Re: Add partial :-variable expansion to psql \copy
От | Tom Lane |
---|---|
Тема | Re: Add partial :-variable expansion to psql \copy |
Дата | |
Msg-id | 3881342.1743433798@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Add partial :-variable expansion to psql \copy (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: Add partial :-variable expansion to psql \copy
Re: Add partial :-variable expansion to psql \copy Re: Add partial :-variable expansion to psql \copy |
Список | 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 по дате отправления: