Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

COPY INTO does not work correctly with backslashes in VARCHARs #2748

monetdb-team opened this issue Nov 30, 2020 · 0 comments

COPY INTO does not work correctly with backslashes in VARCHARs #2748

monetdb-team opened this issue Nov 30, 2020 · 0 comments


Copy link

@monetdb-team monetdb-team commented Nov 30, 2020

Date: 2010-12-10 11:41:42 +0100
From: Daniel Boesswetter <<daniel.boesswetter>>
To: SQL devs <>
Version: 2.40.1 (Oct2010) [obsolete]
CC: @njnes

Last updated: 2011-03-28 17:31:39 +0200

Comment 15305

Date: 2010-12-10 11:41:42 +0100
From: Daniel Boesswetter <<daniel.boesswetter>>

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101206 Ubuntu/9.10 (karmic) Firefox/3.6.13
Build Identifier:

Obviously, MonetDB counts the number of chars for a VARCHAR-field before removing backslashes which are used e.g. for escaping newlines or other backslashes and rejects strings that should actually fit.

Reproducible: Always

Steps to Reproduce:

  1. In mclient: CREATE TABLE t (x VARCHAR(1));
  2. Create a textfile foo.txt containing two backslashes: \
  3. In mclient:
    sql>copy into t from '/tmp/foo.txt';

Actual Results:

SQLException:importTable:value '\' from line 1 field 1 not inserted, expecting type varchar(1)
failed to import table

Expected Results:

There should be one line in t with x containing "".

Performing exactly the same steps with a VARCHAR(2) column works without errors and results in t.x containg the de-escaped single backslash.

Comment 15332

Date: 2010-12-10 22:12:57 +0100
From: @njnes

fixed by correctly counting the string length of the to be inserted string (after escaped chars were converted).

Comment 15334

Date: 2010-12-10 22:14:09 +0100
From: @njnes

Changeset 450e5aadc00c made by Niels Nes in the MonetDB repo, refers to this bug.

For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=450e5aadc00c

Changeset description:

fixed bug #2748 and added test for it

The string length check is now done based on the
string after escape conversion.

Comment 15646

Date: 2011-03-28 17:31:39 +0200
From: @sjoerdmullender

The Mar2011 version has been released.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant