Re: Fixing backslash dot for COPY FROM...CSV - Mailing list pgsql-hackers

From Sutou Kouhei
Subject Re: Fixing backslash dot for COPY FROM...CSV
Date
Msg-id 20240801.064949.1462644340598239046.kou@clear-code.com
Whole thread Raw
In response to Re: Fixing backslash dot for COPY FROM...CSV  ("Daniel Verite" <daniel@manitou-mail.org>)
List pgsql-hackers
Hi,

In <4ffb7317-7e92-4cbd-a542-1e478af6ad5d@manitou-mail.org>
  "Re: Fixing backslash dot for COPY FROM...CSV" on Wed, 31 Jul 2024 15:42:41 +0200,
  "Daniel Verite" <daniel@manitou-mail.org> wrote:

>> BTW, here is a diff after pgindent:
> 
> PFA a v5 with the cosmetic changes applied.

Thanks for updating the patch.

>> I also confirmed that the updated server and non-updated
>> psql compatibility problem (the end-of-data "\." is
>> inserted). It seems that it's difficult to solve without
>> introducing incompatibility.
> 
> To clarify the compatibility issue, the attached bash script
> compares pre-patch and post-patch client/server combinations with
> different cases, submitted with different copy variants.
> 
> case A: quoted backslash-dot sequence in CSV
> case B: unquoted backslash-dot sequence in CSV
> case C: CSV without backslash-dot
> case D: text with backslash-dot at the end
> case E: text without backslash-dot at the end
> 
> The different ways to submit the data:
> copy from file
> \copy from file
> \copy from pstdin
> copy from stdin with embedded data after the command
> 
> Also attaching the tables of results with the patch as it stands.
> "Failed" is when psql reports an error and "Data mismatch"
> is when it succeeds but with copied data differing from what was
> expected.
> 
> Does your test has an equivalent in these results or is it a different
> case?

Sorry for not clarify my try. My try was:

Case C
+----------+----------------+
|  method  | patched-server+|
|          | unpatched-psql |
+----------+----------------+
| embedded | Data mismatch  |
+----------+----------------+

I confirmed that this case is "Data mismatch".



Thanks,
-- 
kou



pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin
Next
From: Ilya Gladyshev
Date:
Subject: Re: optimizing pg_upgrade's once-in-each-database steps