Linter does not recursively validate expressions

[ssandler]

The following query with a bogus CASE expression properly fails the linter:

./lint-query --query "SELECT CASE foo FROM bar"
#1: Unexpected keyword. (near "FROM" at position 16)
#2: Unexpected end of CASE expression (near " " at position 15)

But wrapping the bogus CASE in another expression like an aggregate function will pass the linter. Based on looking at the assembled statements when running the parser it seems like it's not parsing the inner expression.

./lint-query --query "SELECT SUM(CASE foo) FROM bar"

[bigwhoop]

I'm having a similar problem

lint-query --query "SELECT 1 IS NOT NULL AS foo"
#1: Unrecognized keyword. (near "IS" at position 9)
#2: Unrecognized keyword. (near "NOT NULL" at position 12)
#3: Unrecognized keyword. (near "AS" at position 21)

vs.

lint-query --query "SELECT (1 IS NOT NULL) AS foo"

[Moishe]

This is probably the same problem: if I pass a query with a subquery like:

SELECT a,b FROM foo WHERE x IN (SELECT c FROM bar WHERE d IS NOT NULL)

to PhpMyAdmin\SqlParser\Parser, the resulting statement array is of length 1 with a WHERE clause that looks like this:

    [where] => Array
        (
            [0] => PhpMyAdmin\SqlParser\Components\Condition Object
                (
                    [identifiers] => Array
                        (
                            [0] => x
                            [1] => c
                            [2] => bar
                            [3] => d
                        )

                    [isOperator] =>
                    [expr] => x IN (SELECT c FROM bar WHERE d IS NOT NULL)
                )
        )

It seems like maybe there was a similar bug in phpmyadmin itself https://github.com/phpmyadmin/sql-parser/issues/52

[williamdes]

I am closing this very old one, as I tried the lint-query commands and none of them did complain. So everything is probably fixed