public inbox for [email protected]
help / color / mirror / Atom feedFrom: Joel Jacobson <[email protected]>
To: Tom Lane <[email protected]>
Cc: [email protected]
Subject: Re: [BUG] psql: Make \copy from 'text' and 'csv' formats fail on NUL bytes
Date: Sun, 10 Nov 2024 22:50:59 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
On Sun, Nov 10, 2024, at 22:37, Tom Lane wrote:
> "Joel Jacobson" <[email protected]> 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
view thread (2+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: [BUG] psql: Make \copy from 'text' and 'csv' formats fail on NUL bytes
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox