On Sun, Nov 10, 2024, at 23:14, Tom Lane wrote:
> "Joel Jacobson" writes:
>> On Sun, Nov 10, 2024, at 22:37, Tom Lane wrote:
>>> 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 behav
"Joel Jacobson" writes:
> On Sun, Nov 10, 2024, at 22:37, Tom Lane wrote:
>> 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 on
On Sun, Nov 10, 2024, at 22:37, Tom Lane wrote:
> "Joel Jacobson" 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 t
"Joel Jacobson" 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 f
Hi hackers,
When using \copy from in psql to import files containing NUL bytes (\0) in
'text' or 'csv' format, the NUL bytes were not detected and did not result in
an error, leading to silent data corruption.
This behavior is inconsistent with server-side COPY FROM, which reports an error
upon e
