Re: BUG #15535: psql: \copy: parse error at...
От | Tom Lane |
---|---|
Тема | Re: BUG #15535: psql: \copy: parse error at... |
Дата | |
Msg-id | 7732.1544033557@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #15535: psql: \copy: parse error at... ("Daniel Verite" <daniel@manitou-mail.org>) |
Список | pgsql-bugs |
"Daniel Verite" <daniel@manitou-mail.org> writes: > Tom Lane wrote: >> Yeah, that is an issue all right. It occurs to me that for the COPY TO >> side, we don't really need any new command: we could just make \g work >> for that case. (Testing, it seems that plain "\g" works fine already, >> but "\g foo" fails to redirect the COPY output, which seems to me to >> be arguably a bug as well as lack of useful functionality.) >> >> That approach does nothing for COPY FROM, though. On the other hand, >> it's not needed nearly as bad for COPY FROM, since you can't put a >> giant sub-SELECT into that. > Agreed. I will look into the problem of COPY OUT with \g filename > if you don't beat me to it. I wasn't volunteering to work on that, so have at it. > Concerning \copyfrom, the most obvious use case is when the filename > has to be a variable, which \copy doesn't allow for. > But this one might be better solved by just improving \copy. I wonder ... would it be outrageous for "\g foo" to be interpreted as reading foo, not writing it, if what comes back from the server is a CopyInResponse message rather than a query result or CopyOutResponse? No new commands that way, but maybe more potential for user confusion, so I'm not sure if this is a good idea or not. regards, tom lane
В списке pgsql-bugs по дате отправления: