"Daniel Verite" <dan...@manitou-mail.org> writes:
> [ 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.
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.
(This passes check-world as it stands, indicating we have no
existing test that expects this case to work.)
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?
regards, tom lane
diff --git a/src/backend/commands/copyfromparse.c b/src/backend/commands/copyfromparse.c
index a280efe23f..2ea9679b3c 100644
--- a/src/backend/commands/copyfromparse.c
+++ b/src/backend/commands/copyfromparse.c
@@ -1426,13 +1426,17 @@ CopyReadLineText(CopyFromState cstate)
}
/*
- * Transfer only the data before the \. into line_buf, then
- * discard the data and the \. sequence.
+ * If there is any data on this line before the \., complain.
+ */
+ if (cstate->line_buf.len > 0 ||
+ prev_raw_ptr > cstate->input_buf_index)
+ ereport(ERROR,
+ (errcode(ERRCODE_BAD_COPY_FILE_FORMAT),
+ errmsg("end-of-copy marker corrupt")));
+
+ /*
+ * Discard the \. and newline, then report EOF.
*/
- if (prev_raw_ptr > cstate->input_buf_index)
- appendBinaryStringInfo(&cstate->line_buf,
- cstate->input_buf + cstate->input_buf_index,
- prev_raw_ptr - cstate->input_buf_index);
cstate->input_buf_index = input_buf_ptr;
result = true; /* report EOF */
break;
