On Fri, Jan 25, 2019 at 01:01:22PM +0100, Daniel Verite wrote: > Bruce Momjian wrote: > > > but I am able to see the failure using STDIN: > > > > COPY test FROM STDIN CSV; > > Enter data to be copied followed by a newline. > > End with a backslash and a period on a line by itself, or an EOF > > signal. > > "foo > > \. > > ERROR: unterminated CSV quoted field > > CONTEXT: COPY test, line 1: ""foo > > > > This seems like a bug to me. Looking at the code, psql issues the > > prompts for STDIN, but when it sees \. alone on a line, it has no idea > > you are in a quoted CSV string, so it thinks the copy is done and sends > > the result to the server. I can't see an easy way to fix this. I guess > > we could document it. > > Thanks for looking into this. > > \copy from file with csv is also affected since it uses COPY FROM > STDIN behind the scene. The case of embedded data looks more worrying > because psql will execute the data following \. as if they were > SQL statements. > > ISTM that only ON_ERROR_STOP=on prevents the risk of SQL injection > in that scenario, but it's off by default.
You are correct that someone having data that is SQL commands would be able to perhaps execute those commands on restore. pg_dump doesn't use CSV, and this only affects STDIN, not files or PROGRAM input. I think the question is how many people are using CSV/STDIN for insecure data loads? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +