Brook Milligan <brook@biology.nmsu.edu> writes:
> It seems to me that we ought to provide both behaviors, but make sure
> that the one that supports data-in-the-script is the one invoked by
> COPY FROM STDIN (since that's what pg_dump uses). Perhaps psql's \copy
> command can be set up to support the other alternative.
> But isn't there a greater difference between copy and \copy than this?
> Doesn't one act on the frontend and one on the backend?
Not when it's COPY FROM STDIN or TO STDOUT --- from the backend's point of
view, that means transfer data from or to the frontend. What psql
does with it is psql's concern.
(Actually, \copy is implemented by sending a COPY FROM STDIN/TO STDOUT
command to the backend; the backend can't tell the difference between
the two cases, and has no way to know where the data is really coming
from or going to on the client side.)
> - Introduce a new syntax for the 6.5.2 here-doc semantics.
> Possibilities might include COPY FROM HERE (copy ends at EOF or \.)
Changing the SQL command is the wrong thing to think about, because
the parameter would only be known at the backend which is not where
it needs to be known to change psql's behavior. Furthermore, from
the backend's point of view it *is* sending to or from the only
"user interface" it's got. So I don't think there's anything wrong
with the definition of the SQL COPY command. You should be thinking
about adding options to psql's \copy, instead, if you want more
flexibility in controlling where psql gets or puts data.
> pg_dump would have to be changed to correspond.
IMHO any proposal that requires changing pg_dump is a non-starter,
because it will fail when people try to load 6.5 or earlier dumps
into 7.0. But fortunately, pg_dump doesn't use \copy ...
regards, tom lane