SQLの文法こうだったらよかったのに会議

Misreading Chat にて Google Standard SQL のパイプ演算子の論文が紹介されていた。

misreading.chat

論文でSQLの問題として指摘されている点は構文の書き順と評価順が違うと言う点で、そのこ自体は誰しも同意すると思うけれど、パイプ演算子を持ち込むべきであるという解決方法に同意する人はあまりいないのではないか。

SQLにおいて構文と評価順で大きくことなるのは先頭のSELECT部分だけでそれ以外はおおむね評価順通りだったりする。であれば単純に次のような構文にするだけで現在の構文を大きく変えることなく実現できる。

SELECT FROM から始まる場合は RETURNING 句を必須にする

現在のSQLでは INSERT や UPDATE 文に更新後の値を取得できる RETURNING 句が指定できる。これを SELECT 文にも展開すればいい。例えば次のようになる。（先頭にSELECT を残しているのは、SQLでは基本的に先頭の単語がコマンドを表すため）

SELECT FROM tbl
WHERE tbl.x = 1
ORDER BY tbl.y
RETURNING tbl.x, tbl.y

集計時何度も集計関数を書かなければならないという問題もAGGREGATE 句を導入し別名を書けるようにすればよいだけだし、実際PostgreSQL や MySQL では標準SQLとは異なり SELECT リスト内の別名で集計が可能となっている。

SELECT FROM tbl
AGGRIGATE SUM(tbl.a) AS a_sum
  GROUP BY tbl.x
  HAVING a_sum > 1000
ORDER BY tbl.a_sum, tbl.x 
RETURNING tbl.x, tbl.sa

他に問題はないのか

SQLを書く上で一番の問題は決して構文の書き順と評価順が違うことではないと個人的には思う。一番やっかいなのはケツカンマが書けないことによるメンテナンス性の低さだ。コピペで列を追加してエラーになりました、という経験を持つ人も多いと思う。JavaScript を中心に最近の言語ではケツカンマをかけるようになっている言語も増えてきているものの、SQLでそれができるようになることは期待できない。なぜなら、SQLは構文が構造的な作りになっていないからだ。

一般的なプログラミング言語が中かっこや小かっこによって構文の入れ子構造を明確にできるようになっているのに対し、SQLは当時のはやりを反映して自然言語風な文法となっている。そのような文法においてカンマのありなしは解析を難しくする。その上、IS DISTINCT FROM という演算子のように一見特別な予約語のように見える FROM すら普通に文中に発生しうる。

この解決策としては、リスト的な要素は小括弧で囲んでもよく、囲んだ場合にはケツカンマを認めるというルールを導入するのがよいだろう。カンマと閉じ括弧が連続する場合はカンマを無視するだけでよい。

SELECT FROM tbl
RETURNING (
  tbl.x,
  tbl.y,
)

これくらいの文法変更ならリーズナブルではないかと思うのだけど。