From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Artur Zakirov <zaartur(at)gmail(dot)com>, Sutou Kouhei <kou(at)clear-code(dot)com>, bruce(at)momjian(dot)us, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Fixing backslash dot for COPY FROM...CSV |
Date: | 2024-10-01 19:34:20 |
Message-ID: | 4af45b35-ad25-4560-88ba-7e8c8d88033f@manitou-mail.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> > [ v6-0001-Support-backslash-dot-on-a-line-by-itself-as-vali.patch ]
>
> I did some more work on the docs and comments, and pushed that.
Thanks!
> Returning to my upthread thought that
>
> >>> I think we should fix it so that \. that's not alone on a line
> >>> throws an error, but I wouldn't go further than that.
>
> here's a quick follow-on patch to make that happen. It could
> probably do with a test case to demonstrate the error, but
> I didn't bother yet pending approval that we want to do this.
+1 for fixing. In particular, the behavior that silently drops data
after a misplaced marker seems hard to argue for:
postgres=# \copy foo(c1,c2) from stdin
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.
>> a b
>> c \.
>> d e
>> \.
COPY 2
postgres=# table foo;
c1 | c2
----+----
a | b
c |
(2 rows)
> Also, I used the same error message "end-of-copy marker corrupt"
> that we have for the case of junk following the marker, but
> I can't say that I think much of that phrasing. What do people
> think of "end-of-copy marker is not alone on its line", instead?
Yes, it's more precise and more helpful.
Best regards,
--
Daniel Vérité
https://postgresql.verite.pro/
Twitter: @DanielVerite
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2024-10-01 19:58:03 | Re: Using per-transaction memory contexts for storing decoded tuples |
Previous Message | Jacob Champion | 2024-10-01 19:04:53 | Re: pg_parse_json() should not leak token copies on failure |