Tom Lane wrote:
> Currently, copy.c rejects newline, carriage return, and backslash as
> settings for the column delimiter character (in non-CSV mode). These
> all seem necessary to avoid confusion. However, I just noticed that the
> letters r, n, t, etc would also not work: on output, data characters
> matching such a delimiter would get escaped as \r, \n, etc, which on
> input would be read as C-style control characters.
> I think at minimum we need to forbid b, f, n, r, t, v, which are the
> control character representations currently recognized by COPY.
> But I'm tempted to make it reject all 26 lower-case ASCII letters,
> as a form of future-proofing. Thoughts?
Assuming this is only for non-CSV mode, it seems OK.
In response to
pgsql-hackers by date
|Next:||From: Andrew Sullivan||Date: 2007-12-27 18:14:19|
|Subject: Re: Spoofing as the postmaster|
|Previous:||From: Andrew Dunstan||Date: 2007-12-27 16:39:29|
|Subject: Re: Binary data type with other output method|
pgsql-patches by date
|Next:||From: Tom Lane||Date: 2007-12-27 18:32:01|
|Subject: Re: Unworkable column delimiter characters for COPY |
|Previous:||From: Tom Lane||Date: 2007-12-27 15:37:07|
|Subject: Unworkable column delimiter characters for COPY|