Correct Handling of Negative Numerical Literals

[dey4ss]

As mentioned by @JoyBinY in #213, the parser does not handle negative numerical literals correctly in all cases, especially for INSERT statements.

Code for Reproduction:

INSERT INTO foo VALUES (1, 'bar', -2);
                                  ^=== ERROR HERE!     

An INSERT INTO ... VALUES statement has a literal list to represent the values. A literal is defined as

literal : string_literal | bool_literal | num_literal | null_literal | date_literal | interval_literal | param_expr;

The numeric literal can be either an integer or a float (both parsed from unsigned values by the lexer). We represent a negative number as unary - operator expression with the numeric literal as input in other cases, which is not a literal anymore.

However, the solution suggested in #213 is not sufficient either, as allowing negative values for all integers also enables, e.g., the following statements:

CREATE TABLE foo (bar VARCHAR(-5));
SELECT  TOP -3 bar FROM foo;

A possible solution (option 1) could be to expand the num_literal definition from:

num_literal : FLOATVAL { $$ = Expr::makeLiteral($1); }
| int_literal;

to something like:

num_literal : FLOATVAL { $$ = Expr::makeLiteral($1); }
| int_literal;
| '-' FLOATVAL { $$ = Expr::makeOpUnary(kOpUnaryMinus, Expr::makeLiteral($2)); }
| '-' int_literal { $$ = Expr::makeOpUnary(kOpUnaryMinus, $2); };

or:

unsigned_num_literal: FLOATVAL { $$ = Expr::makeLiteral($1); }
| int_literal;

num_literal : unsigned_num_literal
| '-' unsigned_num_literal {
  $2->ival = $2->ival * -1;
  $2->fval = $2->fval * -1;
  $$ = $2;  // or just $$ = Expr::makeOpUnary(kOpUnaryMinus, $2); 
};

As the num_literal, in contrast to [INT|FLOAT]VAL and int_literal, is only used in the literal definition, we should not interfere with the definitions requesting unsigned integers.
An alternative (option 2) could be to define unsigned and signed versions of [INT|FLOAT]VAL in the lexer and use these versions accordingly in all definitions.
@Bouncner @klauck @mweisgut what are your opinions on this topic?

Furthermore, I noticed that INSERT statements are not properly tested in the SQL tests, negative numbers in INSERT statement do not appear in our test queries (queries_good.sql), and neither do the permitted examples from above (queries_bad.sql)

[klauck]

My first thought was option 1.
Somehow, I discovered that inserts should support expressions, e.g., insert into t values(1-(5*3), True OR False);.
That is why, I think we could maybe use expr_list instead of literal_list in the insert_statement.
(However, the alias for expressions might be an issue.)

[dey4ss]

I wasn't aware of this, but it makes sense as it also covers CAST in INSERT statements. Maybe also select_no_paren could be an issue for value insertions. Thus, I think it's fair to either introduce a new (restricted) list of expressions or to hand the responsibility for handling such cases to the DBMS.

[klauck]

Full SQL-92 INSERT support is complex (see, e.g., http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt, for full draft). I would be happy with a simple version of expressions and could maybe spend some time for a proposal during the next weeks. What do you mean with "Maybe also select_no_paren could be an issue for value insertions."?

[dey4ss]

I think a subset of (simple) expressions is fair.

What do you mean with "Maybe also select_no_paren could be an issue for value insertions."?

A SELECT statement for one value of an INSERT ... VALUES statement is not guaranteed to return exactly one field, so I thought it's cumbersome to handle. However, if we want to limit the supported expressions, this will be fine.