Morning Spinach, May
Jun 7, 2023
2023-05-05
もう五日ですか・・・。
夜型への移行を試みたが失敗し、寝不足など生活の乱れなどで発熱クラッシュし昨日は欠勤。今日は回復してきたが気力がなく欠勤。来週からは復帰したい。
諸事情により寝室から kicked-out されてしまうので、リビングで作業する環境をつくりたい。ということでいくつか方法を考えたが、寝室のデスクトップの vscode server にリビングのラップトップからつなぐ方法を試してみる。いちおうシェルも使える。ターミナルはしょうもないくらい遅いが・・・。
一年ぶりくらいに duckdb 活動をしてしてみようかとクローンしてビルド。
最近どんなかんじなのかとビデオを冷やかす。DuckCon 2023 - State of the Duck - Mark Raasveldt and Hannes Mühleisen - YouTube
めっちゃ開発進んでんな。もうコード読んでもわからないのではと不安。
MotherDuck インテグレーションのためにめちゃ複雑さが高まりそうな話を以前聞いていたのが、それが起きている。たとえば AST を直列化するコードが入っている。ZetaSQL ならともかく君たちは in-process のデータベースじゃないのかい。Proto 的なのをつかわず直列化とか地獄である。そしてこのシリアライザは素人か・・・。このひとたちはデータベースの実力はワールドクラスだが他は素人っぽいのだよな・・・。
まあコードを漫然と眺めていてもはかどらないのでバグでも眺めましょう。
Issues · duckdb/duckdb
550 open. このくらいでまったくビビらないのが大企業人材であるところのわたくしです。
一年前は何らかの方法でこれを整形してマークダウンかなんかにしたような気がする。Markdown がいいかはさておきデータを手元に持ってきて分析したほうがよさそうなのは確かである。
記録 をみるとGH コマンドをつかっている。 なるほど。
今回は・・・前回同様 MD -> Docs といきますかね。つまりコマンドそのままもってくればよい。なお前回は 300 くらいだったらしい。
できた: DuckDB Issues
Docs にコピペ Morrita's DuckDB Issue Traige May 2023 - Google Docs
とりあえずタイトルからして興味がないのを strike-through していくべし。
というわけでトリアージを続けているが、2021 年分すら終わりません・・・。
2023-05-06
体調不安から朝はスキップしたが夕方にちょっと時間ができた。トリアージなので細かいじかんですすめるべき（家計簿のトリアージはいいのか？）
VSCode server 経由で terminal は tunnel server 代とかいらなくて便利なんだけど、遅いなあ。やはり managed で native な ssh tunning がほしくなる。そんなんあるんか。-> あるが、とてもじゃないけど信頼できませんわ。我慢だな。
2023-05-08
自分の体調が回復したとおもったら今度は妻子が風邪。ここしばらく家族で不調。
出社の前にちょっとだけトリアジる試み。
先日「閉じたら？」とコメントしておいたバグのいくつかは担当により閉じられていた。Bot が必要。
2021 年分は終了しました・・・。2022 年分を見終わったら直し始めようかな。なお半分くらいは 2023 である。もしかしたら 2023 も眺めたほうがいいのかもしれないが、それは 2022 終了時点での気力をもって判断すべし。
2023-05-10
六月分までみて 130/550 とかなんだけど、なんかバグの増加ペース速くない？
バグも割としょうもないのが多く、自分が直せそうのが沢山あるのはいいんだけど品質管理に不安を覚える。単純に質が低いというよりは、機能が多すぎるのだよな。そして機能同士が独立してなくて相互作用があるので、複雑さが爆発するという。ほんとにブラウザ的である。
ただブラウザと比べ API や機能の追加にめちゃおおらかなので、どんどん機能の surface が肥大化していく。このまま 1.0 に突入して大丈夫か？ちょっと scale back したほうがよくない？
Intern の子が duckdb にバカスカコミットしてるのをいて、はーワシもどっかで気楽にインターンとかしたいもんだわ、と思うものなり。当人は別に気楽じゃないんだろうけれども。
たぶんマイナー機能の実装が half-baked なのだろうね。世の中色々 half-baked なものはいっぱいあるのでとやかく言うものではないが、データベースで half-baked だとユーザはちょっと不安になってしまうのではないか。
CSV reader まわりはしょうもないバグが多い割にユーザが結構いて、直しがいがありそうである。
160/550 まできた。目標の 330 までは道半ばである。
2023-05-11
朝ちょっとだけ進めて 179/550. この人たちに必要なのは TPM だな・・・。
2023-05-12
04:23.
needs-reply label が必要だと思うんだけど、あれデフォルト じゃないんだね。
DuckDB Lab, 名門大学発だけあって DB 人材に事欠いてないのはすごいね。いるところ(=データベースの研究室)にはいるよなー。
2022 の終わりまで残り 100 件 aka 一カ月半まで来ました。しかし一カ月半で 100 件とか、なかなかのペースだね。これ破綻してしまわないか。
ちなみにもう 20 個くらい "閉じられるよ" といって close している。自分の感覚だとこの x3 くらい閉じていいかんじだが、そういう価値判断は保留して単なる閉じ忘れだけでこの件数・・・やはり TPM が・・・というかわたくしにクローズ権限くれたらやりますよ・・・。
はっきり閉じられるやつはさておき、議論が stall したり WAI ですよ、とやんわり伝えているが伝わっていなかったり、ビルドが通らないなどのサポート窓口になっているがサポートされている側が蒸発、みたいのが邪魔。
今週中にはおわらせたかったが、明日明後日と早起きできるかは怪しいのであった。というか明後日は外出の用事があるからダメだな・・・。
2023-05-13
2023-05-15
04;27. 月金は通勤ランがないので朝に軽く筋トレをしてみるものなり。
さて・・・typedef 的 type でも同じ問題があるので、これは alter table における type lookup の問題です。テストケースを作ってデバッグすべし。
というわけでテストを書くと、ASAN で死ぬわ・・・。
ところでコードをみると STRUCT, LIST(?), UNION も 扱えそうな雰囲気である。シンタックスがわからんが。テストケースには追加する必要があるでしょう。ついでに use type のネストもできる。再帰とか大丈夫かな・・・（大丈夫だな）。
ASAN はバグではあったが本題とは関係なかった。
なんか色々問題があるな・・・ 1) GetLogicalType() に降ってくる schema が ALTER しようとしているテーブルの schema である。これは、あってるといえばあってるが、そこを探すので良いのか？妥当なサーチオーダーは 1. テーブルの schema -> デフォルトの schema -> システムの schema とかではないのだろうか。2) そもそも user type の schema を指定できない。つまり "ALTER TABLE test_schema.test_t1 ADD COLUMN j memory.main_int" と書けない ("memory." が不正). これは syntax をさぼっているためである。あとで直すべし。
というわけでまず search order をなんとかすべきだが、そのロジックどっかにないんですかね。なんか昔そのへん直した気がするのだがまったく覚えていない。
名前の lookup をさがすと・・・てきとうである（おもいだしてきた）。
https://github.com/duckdb/duckdb/pull/6141 ここでデフォルトの fallback を雑に実装している。これは特に根拠なさそうだな。適当に loosen すればよさげ。
CatalogEntryLookup Catalog::LookupEntry() に unused code. あとで消す・なおす。
適当に lax にするだけでは治らず。
VSCode のデバッガを試してみると動くが・・・なんか xSAN 関係でクラッシュしがちだなあ。デバッグ中は SAN を切れということですかね。
step in できない・・・。
時間切れ。
2023-05-17
2023-05-18
2023-05-19
04:34. 手早く心拍を上げるために縄跳びをしてみたら 300 回飛んだだけで 150. これは手軽でよいのではないか。
さて・・・ Podcast 準備するかな。
2023-05-20
04:40. 今日は 400 回とんでみた。腕が重い。
つづき。
2023-05-22
04:50. 縄跳びし過ぎで腕が筋肉痛のため今日はあとで走りに行こうと思います・・・。
ひきつづき準備。
2023-05-23
04:34. 軽く腕立て腹筋したのち、縄跳びを 100 回ごとに休憩をはさみ 700 回。400 回でくたばると運動量が足らないとおもってインターバル方式にしてみたけど、これだと心拍数が 120-130 くらいまでしかあがらず微妙。150 までいきたい。次回は 200 回で区切るべし。
さて週末したり Podcast 準備したりしているうちに PR がぜんぶマージされてました！めでたい。今日はフォローアップで CREATE TYPE で qualified name を使えるようにします。Grammar をさわらないといけません。
この bison/flex で生成したコードをチェックインするの、ほんとやめてほしいなしかし。一方でバージョンとかがめんどいというのは理解できるので、こういうツールこそ wasm にしてバイナリをチェックインし、クロス環境で実行できるようにしてほしいもんだわ。
なんかこの文法 は直感的にはおかしいよな。STRUCT とかは TypeName の producdtion なのに、ENUM だけここにハードコードされている。一方で ENUM は SELECT から定義できるという狂った仕様をサポートされているらしく、それだと TypeName に入れるのは厳しいのもわかる。つまり... SQL is crazy, as always.
さてどこをいじるべきか...と PR を見直すと、直すべきは CREATE TYPE ではなく ALTER TABLE だった。
さて微妙・・・。GenericTypeName はコメントに反して qualified name をサポートしていない。一方 SELECT とかで使われる qualified name は quote とかをサポートしている。ALTER TABLE ADD COLUMN i "my_scheme.my_int" とか書けてしまうのはいいのか？まあ別にいいか（てきとう）・・・。
ていうかさ、cataloname.schemaname.columname は OK だが thereis.no.nested.schemanae.here なのか。つまり dot は二つまで。SQL is crazy as always....
そして下手に GenericType で qualified name をサポートしてしまうと、TypeName を使っている場所すべてで qualified name に対処しないといけなくなる。これはそれなりに big change じゃないですか。いきなり PR を送り付けるのもアレなのでいちおう Issue を file しておくか。
まず PG で挙動を確認すべし。
なんか CREATE TYPE myint AS numeric; とかいう時点で既に PG 互換じゃなくない？ PG は CREATE TYPE mytype AS (intval AS numeric); みたいな composite type はサポートしているけど typedef 的な用途はサポートしてないよねこれ。一方の Duck は STRUCT はサポートしているが PG のような伝統的 data type はサポートしてない。互換性考慮する必要なし。
Feature Request: Support qualified name in TypeName · duckdb/duckdb · Discussion #7643
時間切れ。
2023-05-24
05:05. 目覚ましつけわすれ :-(
さて .y いじってくぞ。
これ型名だけじゃなく関数名も qualify できないっぽいな・・・。
うーむできん。時間切れ。やや大がかりなリファクタリングをしないといけなさげ。
具体的にはいままでは雑に grammar.y に埋め込んであったコードを、grammar.y から呼ばれている C++ の "backend" 関数からアクセスできるようにしないといけない。めんどくさいな・・・。
本来なら .cpp に置きたい関数をテンプレートにして .hpp におき、依存したい関数は引数で渡すか・・・。
2023-05-31
05:15. 起きられず。そして WP で一週間分（といっても寝過ごし多数のため実質二日分くらい）の記録が消えてしまった。WP ちゃん・・・あんたにゃ autosave が必要だよ・・・。
この時間じゃなんもできないけど、せめて失われたコンテクストを取り戻し翌日に備えるべし。
なんだっけ？ ALTER TABLE の奇妙なシンタックスの理解を深める必要があった。PG のマニュアルでも見てみるか。
"ALTER [ COLUMN ] column_name SET ( attribute_option = value [, … ] )" これだな・・・。
"SET ( storage_parameter [= value] [, … ] )" というのもあるな。
Bison のでだした counterexample をみると
その文法 PG になくない・・・？
Duck でためしてみると
ALTER TABLE tbl ALTER i SET(foo = bar); もおなじ。
つまり実装されてもおらず PG にも storage_parameter くらいしか使われていないしょーもないエッジケースである。ので、多少表現力を弱くしてもばちはあたるまい。
なお同じ文法をつかう CREATE TABLE tbl2 (i int32) WITH (foo = bar); は動くが・・・、おめーそれエラーチェックしてないだけだろ。CREATE VIEW, CREATE INDEX も同様のオプションをサポートしている（文法レベルでは）。
しかし PG のマニュアルをみると・・・けっこう色々できるね。ストレージに渡すオプションらしい。Duck がエラーをチェックしてないのは確かだが、ここが柔軟な dict になっていてほしいのは事実の模様。ただ key = value の右辺 def_arg が option の指定でそんなに厳しい必要ないだろ・・・とおもったら constraint の指定と文法をシェアしているらしい。ここで constraint 用と create/alter 一族用の表現力に差をつければいいのではないか？
時間切れ。明日は早起きしたいですね・・・。
ていうか五月おわっちゃったよ。
DuckCon に申し込んでいたが、なんとその日は子の学校の林間学校、というかキャンプで親同伴なのだった。はー Duck 勢がわざわざオランダから来てくれるというのに残念。しかし親業というのはそういう楽しみをポイポイ投げ捨てながらやるものなのです。
明日