バベルの図書館は完成しない

Extended outer memory module
for my poor native memory.

Posts:
2022/02/13 クラビスの CTO になりました
2020/09/28 gendoc という YAML からドキュメントを生成するコマンドを作った
2020/09/13 ISUCON10 の予選を 7 位で通過した
2019/12/01 Puma の内部構造やアーキテクチャを追う
2019/05/27 Golang の正規表現ライブラリの処理の流れをざっくり掴む
2019/04/29 InnoDB の B+Tree Index について
2019/04/29 InnoDB における index page のデータ構造
2019/04/28 InnoDB はどうやってファイルにデータを保持するのか
2019/01/06 Designing Data-Intensive Applications を読んでいる
2019/01/03 年末年始に読んだ本について、など
2019/01/01 Ruby から ffi を使って Rust を呼ぶ
2018/11/10 ブラウザにおける状態の持ち方
2018/07/01 Rust で web アプリ、 或いは Rust における並列処理
2018/05/14 なぜテストを書くのか
2018/05/13 Rust で wasm 使って lifegame 書いた時のメモ
2018/03/12 qemu で raspbian のエミュレート(環境構築メモ)
2018/03/12 qemu で xv6 のエミュレート(環境構築メモ)
2018/03/03 Ruby の eval をちゃんと知る
2018/02/11 Web のコンセプト
2018/02/03 Rspec のまとめ
2018/02/03 Ruby を関数型っぽく扱う

MySQL のパーサ

故あって MySQL ターゲットに生成された SQL をパースして構造化した上である判定に使いたくなっている

外部のライブラリに頼る手もなくはないんだけど、信頼性とか仕様への追従面を考えるとなるべくなら MySQL Server が公式に利用しているパーサをそのままそこだけ流用したい。

このクエリはもともと Rails の ActiveRecord 経由で生成されるので、モデルからのメソッドコールで SQL を作成する際の中間表現みたいなものを見て今回の目的のために判定する方が筋がいいのかもしれないんだけど、どっちが構造変わりにくいかで考えると MySQL の公式のクエリパーサかなあと思っている。

ただシンプルな SELECT 文だけなのでまあ正規表現で頑張れないこともなくて、実際今は正規表現で頑張っている。

MySQL の SQL のトークナイズ & パースは lex と yacc を使って実装されている?のかな。 bison も make しているけど lex とか yacc とか bison とかの役割や関係性が全然わかってないから責務や使い方から調べて流用できるのか調査しないとだな…。

以下のあたりが関係ありそうかな 🤔

2019/05/23 00:09
tags: minipost
This site is maintained by furuhama yusuke.
from 2018.02 -