dbTalk Databases Forums  

Re: [PATCHES] [BUGS] BUG #2221: Bad delimiters allowed in COPY ...

mailing.database.pgsql-bugs mailing.database.pgsql-bugs


Discuss Re: [PATCHES] [BUGS] BUG #2221: Bad delimiters allowed in COPY ... in the mailing.database.pgsql-bugs forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Neil Conway
 
Posts: n/a

Default Re: [PATCHES] [BUGS] BUG #2221: Bad delimiters allowed in COPY ... - 01-29-2006 , 09:20 PM






On Sun, 2006-01-29 at 17:03 -0800, David Fetter wrote:
Quote:
Another followup, this time with the comment done right.
+ /* Disallow the forbidden_delimiter strings */
+ if (strcspn(cstate->delim, BADCHARS) != 1)
+ elog(ERROR, "COPY delimiter cannot be %#02x",
+ *cstate->delim);
+

The comment is still wrong: referencing "forbidden_delimiter" makes it
sound like there is something named forbidden_delimiter, but there is
not (at least in the patch as submitted).

The patch should also use ereport rather than elog, because this error
message might reasonably be encountered by the user.

-Neil



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org


Reply With Quote
  #2  
Old   
David Fetter
 
Posts: n/a

Default Re: [PATCHES] [BUGS] BUG #2221: Bad delimiters allowed in COPY ... - 01-30-2006 , 12:47 AM






--UlVJffcvxoiEqYs2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Sun, Jan 29, 2006 at 10:20:47PM -0500, Neil Conway wrote:
Quote:
On Sun, 2006-01-29 at 17:03 -0800, David Fetter wrote:
Another followup, this time with the comment done right.

+ /* Disallow the forbidden_delimiter strings */
+ if (strcspn(cstate->delim, BADCHARS) != 1)
+ elog(ERROR, "COPY delimiter cannot be %#02x",
+ *cstate->delim);
+

The comment is still wrong: referencing "forbidden_delimiter" makes
it sound like there is something named forbidden_delimiter, but
there is not (at least in the patch as submitted).

The patch should also use ereport rather than elog, because this
error message might reasonably be encountered by the user.
Patch with BADCHARS attached

Cheers,
D
--
David Fetter david (AT) fetter (DOT) org http://fetter.org/
phone: +1 415 235 3778

Remember to vote!

--UlVJffcvxoiEqYs2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="forbid_badchars_copy.diff"

Index: src/backend/commands/copy.c
================================================== =================
RCS file: /projects/cvsroot/pgsql/src/backend/commands/copy.c,v
retrieving revision 1.257
diff -c -r1.257 copy.c
*** src/backend/commands/copy.c 28 Dec 2005 03:25:32 -0000 1.257
--- src/backend/commands/copy.c 30 Jan 2006 06:44:10 -0000
***************
*** 51,56 ****
--- 51,57 ----

#define ISOCTAL(c) (((c) >= '0') && ((c) <= '7'))
#define OCTVALUE(c) ((c) - '0')
+ #define BADCHARS "\r\n\\"

/*
* Represents the different source/dest cases we need to worry about at
***************
*** 856,861 ****
--- 857,869 ----
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("COPY delimiter must be a single character")));

+ /* Disallow BADCHARS characters */
+ if (strcspn(cstate->delim, BADCHARS) != 1)
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("COPY delimiter cannot be \"%#02x\"",
+ *cstate->delim)));
+
/* Check header */
if (!cstate->csv_mode && cstate->header_line)
ereport(ERROR,

--UlVJffcvxoiEqYs2
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

--UlVJffcvxoiEqYs2--


Reply With Quote
  #3  
Old   
Andrew Dunstan
 
Posts: n/a

Default Re: [PATCHES] [BUGS] BUG #2221: Bad delimiters allowed in COPY ... - 01-30-2006 , 07:35 AM





David Fetter wrote:

Quote:
+ /* 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.
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)

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings


Reply With Quote
  #4  
Old   
David Fetter
 
Posts: n/a

Default Re: [PATCHES] [BUGS] BUG #2221: Bad delimiters allowed in COPY ... - 01-30-2006 , 12:16 PM



On Mon, Jan 30, 2006 at 08:21:34AM -0500, Andrew Dunstan wrote:
Quote:

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.

Quote:
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 (AT) fetter (DOT) org http://fetter.org/
phone: +1 415 235 3778

Remember to vote!

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match


Reply With Quote
  #5  
Old   
Bruce Momjian
 
Posts: n/a

Default Re: [PATCHES] [BUGS] BUG #2221: Bad delimiters allowed in COPY ... - 01-31-2006 , 04:24 PM



Quote:
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.

Quote:
Maybe ERRCODE_INVALID_PARAMETER_VALUE ? Or maybe we need a new one.
Agreed. Right now it is invalid and there are no plans to support other
values for end-of-line. I will make the change when the patch is
applied.

--
Bruce Momjian | http://candle.pha.pa.us
pgman (AT) candle (DOT) pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend


Reply With Quote
  #6  
Old   
Bruce Momjian
 
Posts: n/a

Default Re: [PATCHES] [BUGS] BUG #2221: Bad delimiters allowed in COPY ... - 01-31-2006 , 07:04 PM




Uh, couldn't the delimiter be a backslash in CVS mode?

+ #define BADCHARS "\r\n\\"

Also, should we disable DELIMITER and NULL from sharing characters?

---------------------------------------------------------------------------

David Fetter wrote:
Quote:
On Sun, Jan 29, 2006 at 10:20:47PM -0500, Neil Conway wrote:
On Sun, 2006-01-29 at 17:03 -0800, David Fetter wrote:
Another followup, this time with the comment done right.

+ /* Disallow the forbidden_delimiter strings */
+ if (strcspn(cstate->delim, BADCHARS) != 1)
+ elog(ERROR, "COPY delimiter cannot be %#02x",
+ *cstate->delim);
+

The comment is still wrong: referencing "forbidden_delimiter" makes
it sound like there is something named forbidden_delimiter, but
there is not (at least in the patch as submitted).

The patch should also use ereport rather than elog, because this
error message might reasonably be encountered by the user.

Patch with BADCHARS attached

Cheers,
D
--
David Fetter david (AT) fetter (DOT) org http://fetter.org/
phone: +1 415 235 3778

Remember to vote!
[ Attachment, skipping... ]

Quote:
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq
--
Bruce Momjian | http://candle.pha.pa.us
pgman (AT) candle (DOT) pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend


Reply With Quote
  #7  
Old   
David Fetter
 
Posts: n/a

Default Re: [PATCHES] [BUGS] BUG #2221: Bad delimiters allowed in COPY ... - 01-31-2006 , 08:48 PM



On Tue, Jan 31, 2006 at 08:03:41PM -0500, Bruce Momjian wrote:
Quote:
Uh, couldn't the delimiter be a backslash in CVS mode?
I don't think so. Folks?

Anyhow, if there are different sets, I could do something like:

#define BADCHARS "\r\n\\"
#define BADCHARS_CSV "\r\n"

and then check for csv_mode, etc.

Quote:
+ #define BADCHARS "\r\n\\"

Also, should we disable DELIMITER and NULL from sharing characters?
That's on about line 916, post-patch:

/* Don't allow the delimiter to appear in the null string. */
if (strchr(cstate->null_print, cstate->delim[0]) != NULL)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("COPY delimiter must not appear in the NULL specification")));

I suppose that a different error code might be The Right Thing™ here.

Cheers,
D
--
David Fetter david (AT) fetter (DOT) org http://fetter.org/
phone: +1 415 235 3778

Remember to vote!

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org


Reply With Quote
  #8  
Old   
David Fetter
 
Posts: n/a

Default Re: [PATCHES] [BUGS] BUG #2221: Bad delimiters allowed in COPY ... - 01-31-2006 , 09:45 PM



On Tue, Jan 31, 2006 at 09:50:26PM -0600, Andrew Dunstan wrote:
Quote:
David Fetter said:
On Tue, Jan 31, 2006 at 08:03:41PM -0500, Bruce Momjian wrote:
Uh, couldn't the delimiter be a backslash in CVS mode?

I don't think so. Folks?

Using backslash as a delimiter in CSV would be odd, to say the least. As an
escape char it is occasionally used, but not as a delimiter in my
experience. Maybe we should apply the "be liberal in what you accept" rule,
but I think this would be stretching it.
<aol>So do I.</aol>

Quote:
Also, should we disable DELIMITER and NULL from sharing characters?

That's on about line 916, post-patch:

/* Don't allow the delimiter to appear in the null string. */
if (strchr(cstate->null_print, cstate->delim[0]) != NULL)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("COPY delimiter must not appear in the NULL
specification")));

I suppose that a different error code might be The Right Thing™
here.

ERRCODE_WHAT WERE_YOU_THINKING ?
That's an excellent candidate, or maybe ERRCODE_INVALID_PARAMETER_VALUE.
My vote is for ERRCODE_D00D_WTF

Maybe we need an error code for mutually incompatible param values.

Cheers,
D
--
David Fetter david (AT) fetter (DOT) org http://fetter.org/
phone: +1 415 235 3778

Remember to vote!

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly


Reply With Quote
  #9  
Old   
Andrew Dunstan
 
Posts: n/a

Default Re: [PATCHES] [BUGS] BUG #2221: Bad delimiters allowed in COPY ... - 02-01-2006 , 08:34 AM



David Fetter said:
Quote:
On Tue, Jan 31, 2006 at 08:03:41PM -0500, Bruce Momjian wrote:
Uh, couldn't the delimiter be a backslash in CVS mode?

I don't think so. Folks?
Using backslash as a delimiter in CSV would be odd, to say the least. As an
escape char it is occasionally used, but not as a delimiter in my
experience. Maybe we should apply the "be liberal in what you accept" rule,
but I think this would be stretching it.

Quote:
Anyhow, if there are different sets, I could do something like:

#define BADCHARS "\r\n\\"
#define BADCHARS_CSV "\r\n"

and then check for csv_mode, etc.

+ #define BADCHARS "\r\n\\"

Also, should we disable DELIMITER and NULL from sharing characters?

That's on about line 916, post-patch:

/* Don't allow the delimiter to appear in the null string. */
if (strchr(cstate->null_print, cstate->delim[0]) != NULL)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("COPY delimiter must not appear in the NULL
specification")));

I suppose that a different error code might be The Right Thing™ here.

ERRCODE_WHAT WERE_YOU_THINKING ?

cheers

andrew



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.