Re: Craig Ringer 2016-09-05 <CAMsr+YHP=hTUKpuHK4LOAmWE_JEe-A281QL0uni_gw-V7jQv2w@mail.gmail.com>
> To cover the same-host case we could try something like:
>
> COPY runs on the PostgreSQL server, using the PostgreSQL server's
> directories and permissions, it doesn't run on the client.
>
> ... but I think that's actually less helpful for the users who'll need this.
The part about the server permissions might be useful to hint at.
> > I don't suppose there's any easy way for COPY to distinguish local
> > from remote connections
>
> Not that I see, since "local" can be unix socket or tcp to localhost.
> Not cleanly anyway.
>
> I don't think it matters. Many hosts have enough paths in common that
> in practice the hint on EACCES will be useful anyway. It'd be nice to
> work in something about running with the permissions of the PostgreSQL
> server, but I don't see a way to do that without making it all more
> complex.
>
> I don't think it's worth tons of time anyway. This will be better than
> what we have, lets do it.
It's probably not helpful trying to distinguish local and remote
connections, the set of possible problems is diverse and this is just
one of them.
> I'm fairly happy with the wording you came up with:
>
> "COPY copies to a file on the PostgreSQL server, not on the client. "
> "You may want a client-side facility such as psql's \\copy."
What about
"COPY TO instructs the PostgreSQL server to write to a file on the server. " "You may want a client-side
facilitysuch as psql's \\copy."
"COPY FROM instructs the PostgreSQL server to read from a file on the server. " "You may want a client-side
facilitysuch as psql's \\copy."
This stresses more explicitly that the file is opened by the server
process. (I'm not particularly happy that it says "server" in there
twice, but couldn't think of anything else.)
Christoph