Hello Corey,
If we could do this:
COPY :"myschema".:"mytable" FROM STDIN \g < :"myfilename"
that would fit our patterns most cleanly, but we would probably create a parsing hassle for ourselves if we ever wanted to mix pipe-to with pipe-from. It would also require checking on every command, when uploaded \copy commands make up a very small percentage of commands issued. So I don't think there's a good way around the asymmetry of COPY TO being a regular \g-able command, whereas COPY FROM will always require some other send-command.
Perhaps we create a new command \copyfrom:
COPY :"myschema".:"mytable" :options FROM STDIN \copyfrom :"myfilename"
COPY :"myschema".:"mytable" :options FROM STDIN \copyfrom :"my_complex_command" |
If we had something like that we might be able to replace all existing uses of \copy.
Indeed, I like the idea of extending psql handling of COPY rather than trying to salvage \copy. I do not like that it is probably more work for significantly larger patch.
There are 4 cases to address: input/output cross join file/program, and as you pointed out the output ones are already handled.
I'm hesitating about the right syntax, though, for an input backslash command which in effect would really only apply to COPY? ISTM that \g* is used for "go", i.e. a semi-colon replacement which executes the SQL, and we should want the same thing, which suggests:
COPY "foo" FROM STDIN \gi filename
COPY "foo" FROM STDIN \gi command...|
Another drawback is that it creates an error path:
COPY "foo" FROM 'server-side-file' \gi 'client-side-file'
--
Fabien.
