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:
making it a \g-variant does seem to be natural.
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'
Consider the case:
INSERT INTO mytable (x) VALUES(1) \gi '/path/to/local/file'
Is this an error because we'd be teeing up a file for a command that cannot consume one? How much do we parse the buffer to learn whether we have a query or a COPY command in the buffer? Maybe in the future other commands will take uploaded files, but I would imagine those operations would just leverage the existing COPY functionality inside whatever additional benefits they provide. Until then, this command can only really be used for single COPY foo FROM STDIN statements. With that in mind, I think the name \copyfrom reflects the highly specific utility of the command, and sets boundaries for what is reasonable to have in the query buffer (i.e. one COPY statement, possibly multiline), leaving \gi open for later, more flexible uses.
Looking at the code a bit, \copyfrom would have a variant of do_copy() with a much abbreviated variant parse_slash_copy(), no construction of the copy statement whatsoever, just use the query buffer and let regular SendQuery() error handling take over.
