Re: [PATCHES] BUG #2221: Bad delimiters allowed in COPY ... - Mailing list pgsql-bugs

From David Fetter
Subject Re: [PATCHES] BUG #2221: Bad delimiters allowed in COPY ...
Date
Msg-id 20060130181557.GI6212@fetter.org
Whole thread Raw
In response to Re: [PATCHES] BUG #2221: Bad delimiters allowed in COPY ...  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: [PATCHES] BUG #2221: Bad delimiters allowed in COPY ...  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-bugs
On Mon, Jan 30, 2006 at 08:21:34AM -0500, Andrew Dunstan wrote:
>
>
> David Fetter wrote:
>
> >
> >+     /* Disallow BADCHARS characters */
> >+     if (strcspn(cstate->delim, BADCHARS) != 1)
> >+         ereport(ERROR,
> >+                 (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> >+                  errmsg("COPY delimiter cannot be \"%#02x\"",
> >+                         *cstate->delim)));
> >+
>
> Is  ERRCODE_FEATURE_NOT_SUPPORTED the right errcode? This isn't a
> missing feature; we are performing a sanity check here. We can
> reasonably expect never to support CR, LF or \ as the text
> delimiter.

I guess that depends on whether we ever plan to allow people to set
the output record separator to something other than CR?LF.

> Maybe ERRCODE_INVALID_PARAMETER_VALUE ? Or maybe we need a new one.
>
> Also, I would probably make the format %#.02x so the result would
> look like 0x0d (for a CR).
>
> (I bet David never thought there would so much fuss over a handful
> of  lines of code)

Actually, I'm happy to see it's getting QA.  COPY is something that
has Consequences™ if anything goes wrong with it, so I'd rather do
best efforts up front to get it right. :)

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 415 235 3778

Remember to vote!

pgsql-bugs by date:

Previous
From: Michael Fuhr
Date:
Subject: Re: BUG #2224: unlogical syntax error
Next
From: Neil Conway
Date:
Subject: Re: Bug#347548: DOMAIN CHECK constraint bypassed