Subquery in expressions support

説明

It seems to subqueries are poorly supported

Some examples first:

They are not parsed at all

SELECT * FROM (SELECT * FROM b) a

results in

...
PhpMyAdmin\SqlParser\Components\Expression Object
(
    [database] =>
    [table] =>
    [column] =>
    [expr] => (SELECT * FROM b)
    [alias] => a
    [function] =>
    [subquery] => SELECT
)
...

not even extracted properly (see #254)

SELECT * FROM a WHERE a.field IN (SELECT * FROM b)

results in

...
...
PhpMyAdmin\SqlParser\Components\Condition Object
(
    [identifiers] => Array
        (
            [0] => a
            [1] => field
            [2] => b
        )

    [isOperator] =>
    [expr] => a.field IN (SELECT * FROM b)
)
...

So I have an idea. May be there must be separate ExpressionParser generating AST for expression? Those (including me) who needed parsed expression can use it (and extract subselects, and parse it with regular parser), and there will be no compatibility break.

Does it sounds as a good plan? If it does, I would like to implement it.

はじめの一歩

issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。

着手することを issue にコメントします — 二人が同じ作業をするのを防げます。

リポジトリをフォークし、ブランチを切って変更します。

issue 番号を参照したプルリクエストを送ります。

調査の方向性

まず、既存の式解析の経路と、例で説明されている通常のパーサーを調べます。互換性を維持しながら、独立した ExpressionParser でサブクエリをどのように表現および抽出できるかを判断し、その後、SELECT と WHERE IN の例が利用可能な解析済みサブクエリを生成することを確認します。

索引モデルが issue の本文から書いたものです。

評価

技術スタック

php, sql

領域

compilers

issue の種類

機能追加

難易度

5/5

見積もり時間

1週間以上

活発さ

停滞

明瞭さ

おおむね明確

初心者へのやさしさ

25/100

説明

コントリビューションガイド

はじめの一歩

調査の方向性

評価

新しい issue をメールで受け取る