Sutou Kouhei

Partially, yes. You can't use `grn_table_select()`. You need to use `grn_ii_sel()` (or you can use lower level `grn_ii_select()`) instead.

Mroonga's wrapper mode uses these APIs. This may be able to implement a "black hole" data column (that doesn't store the given data). But I want to think about use...

You can't use query syntax with `grn_obj_search()`. So it seems that `grn_obj_search()` doesn't match your use case.

I found one more use case. It's PGroonga. PostgreSQL implements `UPDATE` by appending a new internal row (tuple in PostgreSQL term) and remove a old internal row. It doesn't change...

I noticed that PGroonga can't use this feature because `VACUUM` needs to delete posting lists in PGroonga index. To delete posting lists effectively, we need source text. Anyway, we accept...

I'm not against using Ubuntu 22.04 but why is it related? `g++`/`clang++` on Ubuntu 20.4 should support C++17.

英語版の https://en.wikipedia.org/wiki/Historical_kana_orthography を見る感じだと`old`よりも`historical`の方がよさそうじゃないですか？ 'ヱビスビール'は`エビスビール`のままでひらがなとカタカナの変換は`unify_kana`に任せませんか？ 「を」はデメリットが多すぎるので対象外でいいんじゃないですかねぇ。

分けるなら`unify_kana_wi_sound`と`unify_kana_we_sound`だけでよくないっすか？ ひらがなだけ・カタカナだけって用途ありますかねぇ。

あぁ、そういうことですか。 そういう意味だとすでに追加した`unify_katakana_*`も`unify_kana_*`でよかったものがありそうな気がしますね。。。（全部？）

Historical kana orthographyらしいので`historical_kana`という順番にして、1音なので`sounds`から`s`をとりませんか？ 例：`unify_historical_kana_wi_sound` `kana_historical`のままで、`historical`を`kana`じゃなくて`wi`とかにかけた方がいいのかしら。