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

From Daniel Verite
Subject Re: Fixing backslash dot for COPY FROM...CSV
Date
Msg-id 4af45b35-ad25-4560-88ba-7e8c8d88033f@manitou-mail.org
Whole thread Raw
In response to Re: Fixing backslash dot for COPY FROM...CSV  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fixing backslash dot for COPY FROM...CSV
List 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



pgsql-hackers by date:

Previous
From: Alexander Lakhin
Date:
Subject: Re: query_id, pg_stat_activity, extended query protocol
Next
From: Masahiko Sawada
Date:
Subject: Re: Using per-transaction memory contexts for storing decoded tuples