parser: implement Restore for VariableExpr

[exialin]

Implement Restore and unit test for VariableExpr.

By the way, the literal string of operator EQ should be = instead of ==, which is fixed.

Issue: pingcap/tidb#8532

[exialin]

@kennytm Hi, I want to discuss two problems with you. After changing to WriteName, some tests will fail.

1. The generated ASTs of select @`a` and select @a are different.

The AST of select @`a` :

*ast.SelectStmt	&{{{{select @`a`}}} {[]} 0xc00000f590 false <nil> <nil> 0xc00000f5c0 <nil> <nil> [] <nil> <nil> none [] false false}
  *ast.FieldList	&{{} [0xc000056660]}
    *ast.SelectField	&{{`a`} 8 <nil> 0xc0000e6960  false}
      *ast.VariableExpr	&{{{} {0 0 0 0   []} 64} a false false false <nil>}

The AST of select @a:

*ast.SelectStmt	&{{{{select @a}}} {[]} 0xc00000f590 false <nil> <nil> 0xc00000f5c0 <nil> <nil> [] <nil> <nil> none [] false false}
  *ast.FieldList	&{{} [0xc000056660]}
    *ast.SelectField	&{{@a} 7 <nil> 0xc00009caa0  false}
      *ast.VariableExpr	&{{{} {0 0 0 0   []} 64} a false false false <nil>}

So they are not deeply equal to each other. In the unit test function, I have to use @`a` but not @a as the source SQL text. But the restored SQL text will work.

2. TiDB doesn't support queries like this while MySQL supports:

tidb> select @@global.`sql_mode`;
ERROR 1193 (HY000): Unknown system variable ''

The AST of select @@global.sql_mode:

*ast.SelectStmt	&{{{{select @@global.sql_mode}}} {[]} 0xc000083500 false <nil> <nil> 0xc000083530 <nil> <nil> [] <nil> <nil> none [] false false}
  *ast.FieldList	&{{} [0xc00007e600]}
    *ast.SelectField	&{{@@global.sql_mode} 7 <nil> 0xc000092aa0  false}
      *ast.VariableExpr	&{{{} {0 0 0 0   []} 64} sql_mode true true true <nil>}

The AST of select @@global.`sql_mode` :

ast.SelectStmt	&{{{{select @@global.`sql_mode`}}} {[]} 0xc000083500 false <nil> <nil> 0xc000083530 <nil> <nil> [] <nil> <nil> none [] false false}
  *ast.FieldList	&{{} [0xc00007e600]}
    *ast.SelectField	&{{} 7 <nil> 0xc000092a00 sql_mode false}
      *ast.VariableExpr	&{{{} {0 0 0 0   []} 64}  true true true <nil>}

As you can see the parser currently doesn't handle such case, so Variable.Name=''. Maybe this syntax should be added, and the test can pass only when it is supported.

[kennytm]

@exialin Thanks for the throughout tests. I think both are bugs in the parser. I've filed #94 and #95.

So we have two paths forward:

1. Use WriteKeyWord instead of WriteName and ignores variables with quoted names, or
2. Wait until those two issues are fixed

I think we should do (1) (use WriteKeyWord) to avoid blocking this PR on these edge cases. WDYT @tiancaiamao @leoppro

[zier-one]

i think we should wait the two issue fixed.

[zier-one]

#112 id merged, please resolve conflicts and run test again @exialin

[exialin]

@leoppro PTAL.
Here's one more problem. The name of system variables are converted to lower cases:

parser/parser.y

Lines 5649 to 5651 in f4f4614

	doubleAtIdentifier
	{
	v := strings.ToLower($1)

But user variables are not. So in the test cases, the names have to be case sensitive for user variables, while insensitive for system variables. Should they be consistent?

[zier-one]

@leoppro PTAL.
Here's one more problem. The name of system variables are converted to lower cases:
parser/parser.y

Lines 5649 to 5651 in f4f4614

doubleAtIdentifier
{
v := strings.ToLower($1)
But user variables are not. So in the test cases, the names have to be case sensitive for user variables, while insensitive for system variables. Should they be consistent?

it doesn't matter, ignore it will be fine

[zier-one]

LGTM, PTAL @kennytm

[zier-one]

@kennytm PTAL

[kennytm]

Rest LGTM.

[kennytm]

LGTM