phpmyadmin / phpmyadmin/sql-parser
Incorrect type in SelectStatement::$expr when query has CASE-clause in selected fields
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 485
- Forks
- 119
- PR merge metrics
- No merged PRs in 30d
Description
The public field SelectStatement::$expr is defined in a PHP docblock as an Expression[]. When parsing a query with a CASE statement, a CaseExpression object is present in this list, despite CaseExpression not extending Expression. This causes issues when explicitly requiring the Expression type as should be returned by SelectStatement::$expr.
Reproduction case
<?php
declare(strict_types=1);
use PhpMyAdmin\SqlParser\Components\Expression;
use PhpMyAdmin\SqlParser\Parser;
use PhpMyAdmin\SqlParser\Statements\SelectStatement;
include_once 'vendor/autoload.php';
$p = new Parser('SELECT a, CASE WHEN b IS NOT NULL THEN 1 ELSE 0 END as c FROM t');
$stmt = $p->statements[0];
if (! $stmt instanceof SelectStatement) {
throw new Exception('Could not parse select statement');
}
function acceptExpression(Expression $e): void {}
$expressions = $stmt->expr;
foreach ($expressions as $expression) {
acceptExpression($expression);
}
Expected behavior
I would expect this script to not error out as the $stmt->expr returns Expression[] according to its PHP docblock. Each element should therefore be compatible with Expression in my acceptExpression function.
Real behavior
$ php test.php
PHP Fatal error: Uncaught TypeError: acceptExpression(): Argument #1 ($e) must be of type PhpMyAdmin\SqlParser\Components\Expression, PhpMyAdmin\SqlParser\Components\CaseExpression given, called in /path/to/test.php on line 22 and defined in /path/to/test.php:18
Stack trace:
#0 /path/to/test.php(22): acceptExpression()
#1 {main}
thrown in /path/to/test.php on line 18
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Parser reproduction in the issue and inspect how SelectStatement::$expr is populated when a CASE clause is selected. Compare the Expression and CaseExpression types and verify the intended contract by rerunning the supplied script; done means the reported TypeError no longer occurs while the expression list remains correctly typed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- databases
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100