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.
