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

Prepared statement of INSERT with SELECT fails when types difer #7230

Closed
nuno-faria opened this issue Jan 26, 2022 · 2 comments
Closed

Prepared statement of INSERT with SELECT fails when types difer #7230

nuno-faria opened this issue Jan 26, 2022 · 2 comments
Labels
bug Something isn't working
Milestone

Comments

@nuno-faria
Copy link
Contributor

Describe the bug
When preparing a statement of inserts with selects, the prepare fails when the parameters have different types.

To Reproduce

  • Create the test table and add some data:

    CREATE TABLE Test (c1 int not null, c2 varchar(255) not null, c3 int not null);
    INSERT INTO Test VALUES (1, 'asd', 1);
  • Create a prepared statement of a insert with select:

    PREPARE INSERT INTO Test
    SELECT c1, ?, ?
    FROM Test;
    -- or PREPARE INSERT INTO Test (c1, c2, c3) SELECT ...
    
    > Internal error while compiling statement: TypeException:user.p0_0[16]:'algebra.select' undefined in:     X_15:any := algebra.select(X_14:bat[:int], X_16:str, X_16:str, true:bit, true:bit, false:bit);

Additional notes

  • If both parameters have the same type, the prepare works correctly. E.g.:

    CREATE TABLE Test (c1 int not null, c2 varchar(255) not null, c3 varchar(255) null);
    INSERT INTO Test VALUES (1, 'asd', 'asd');
    
    PREPARE INSERT INTO Test
    SELECT c1, ?, ?
    FROM Test;
    
    > execute prepared statement using: EXEC 0(...)
    +---------+--------+-------+--------+-------+--------+
    | type    | digits | scale | schema | table | column |
    +=========+========+=======+========+=======+========+
    | varchar |    255 |     0 | null   | null  | null   |
    | varchar |    255 |     0 | null   | null  | null   |
    +---------+--------+-------+--------+-------+--------+
  • The error also does not occur when all the columns are custom parameters, i.e.:

    PREPARE INSERT INTO Test
    SELECT ?, ?, ?
    FROM Test;
    
    > execute prepared statement using: EXEC 0(...)
    +---------+--------+-------+--------+-------+--------+
    | type    | digits | scale | schema | table | column |
    +=========+========+=======+========+=======+========+
    | int     |     32 |     0 | null   | null  | null   |
    | varchar |    255 |     0 | null   | null  | null   |
    | int     |     32 |     0 | null   | null  | null   |
    +---------+--------+-------+--------+-------+--------+
  • The error also does not occur when we remove the not null from the table definition. However, the types are not correct:

    CREATE TABLE Test (c1 int, c2 varchar(255), c3 int);
    INSERT INTO Test VALUES (1, 'asd', 1);
    
    PREPARE INSERT INTO Test
    SELECT c1, ?, ?
    FROM Test;
    
    > execute prepared statement using: EXEC 0(...)
    +------+--------+-------+--------+-------+--------+
    | type | digits | scale | schema | table | column |
    +======+========+=======+========+=======+========+
    | int  |     32 |     0 | null   | null  | null   | -- should be varchar
    | int  |     32 |     0 | null   | null  | null   |
    +------+--------+-------+--------+-------+--------+

    And if we try to use the prepared statement:

    -- trying to pass a string to c2
    EXEC 0('asd', 1);
    > conversion of string 'asd' to type int failed.
    
    -- or trying to pass an integer to c2
    EXEC 0(1, 1);
    > Append failed

Software versions

  • MonetDB v11.43.0 (Jan22 branch)
  • Ubuntu 20.04
  • Self-installed and compiled
@PedroTadim
Copy link
Contributor

Found the issue. Tomorrow I will push the fix.

@PedroTadim PedroTadim added the bug Something isn't working label Jan 27, 2022
@PedroTadim PedroTadim added this to the NEXTRELEASE milestone Jan 27, 2022
monetdb-team pushed a commit that referenced this issue Jan 27, 2022
… copy the flag value, so parameter variables are correctly propagated
@nuno-faria
Copy link
Contributor Author

Can confirm that it is now working correctly. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants