From: | "Joel Jacobson" <joel(at)compiler(dot)org> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: [BUG] psql: Make \copy from 'text' and 'csv' formats fail on NUL bytes |
Date: | 2024-11-10 21:50:59 |
Message-ID: | 1862fe76-b826-4215-bf92-0a4c476e6736@app.fastmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Nov 10, 2024, at 22:37, Tom Lane wrote:
> "Joel Jacobson" <joel(at)compiler(dot)org> writes:
>> Fix by adjusting handleCopyIn() to use the binary code path also when the copy
>> source is a file (i.e., copystream != pset.cur_cmd_source), even in textual
>> copies.
>
> That seems like a hack, as it also changes the behavior w.r.t.
> prompts and EOF-mark detection, neither for the better.
Hmm, in what way does it change the behavior?
I ran almost all the tests, including the TAP ones, and none of them failed with
this fix. Is there some behavior that is currently not covered by the test suite?
> I'm not really convinced that we need to do anything at all
> about this.
I think this should be fixed, because 0x00 is valid UTF-8 for the Unicode
Character 'NULL' (U+0000), which makes me think there is a risk CSV files
coming from other systems than PostgreSQL, could contain such text strings
which would then silently cause data corruption.
/Joel
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-11-10 22:14:38 | Re: [BUG] psql: Make \copy from 'text' and 'csv' formats fail on NUL bytes |
Previous Message | Tomas Vondra | 2024-11-10 21:41:33 | Re: index prefetching |