単純に whr_kw()
で条件を返そうかと考えていたが,準備文を生成しつつ代置子に対応する複数の検索語を返す必要があるため,pre_cnd_kw()
を実装した。返し値はとりあえず文字列配列にしておいたが,いずれ準備文に適した類型が欲しい。
これで dg_fnd()
と dg_cnt_fnd()
を書き直した。だいぶすっきりして,全知検索の調整・拡張がやりやすくなった。
pre_cnd_kw()
}{dg_fnd()
}{dg_cnt_fnd()
}{希哲16年1月13日の進捗時限}{希哲16年1月13日の進捗}...whr_kw()
}{扱いやすくなった}{希哲16年1月12日}...whr_kw()
}{希哲16年1月12日の進捗時限}{希哲16年1月12日の進捗}{希哲16年1月12日}{交度整理}{進捗時限記録}{進捗時限}...whr_kw()
}{希哲16年1月12日の進捗時限}{希哲16年1月12日の進捗}{希哲16年1月12日}{交度整理}{進捗時限記録}...whr_kw()
}{希哲15年8月23日の開発}{検索語変換}{どうとでもなる}{条件次第}{OR 検索}...全文検索にはとりあえず pg_bigm を採用しておくことにした。知名検索でも中間一致検索の性能は課題だったので,これも解決出来そうだ。後方一致検索に関しては,PostgreSQL 9.1 から reverse() が組み込み函数として提供されるようになっているので問題ないだろう。
後縁の実装はどうとでもなるが,難しいのは用合いだ。全知検索窓をこれ以上ごちゃごちゃさせたくないので,まずは検索演算子として各種機能を実装したい。これに関しても,だいぶまとまってきた。
カンマを AND 検索に使うという構想があったが,& ボタンとの兼ね合いもあるので,まずは無難に &
か AND
で AND 検索,|
か OR
でOR 検索に対応することにした。除外検索は条件次第で -
を使えるようにしてもいいだろう。
部分一致検索については,省略記号 ...
とダッシュ記法を応用した ---
に対応する。
描写検索については,基本的には昨年7月27日3歩の方針を踏襲し,末尾に ??
を加える形で対応することにした。デラングとの兼ね合いで検索寸片をどうするかという課題は残るが,デライトではそれほど多用するものではないので,まずは普通に引っかかるだけで十分だろう。
一つの可能性として,検索ボタンをダブルクリック/ダブルクリックで検索対象を切り替える機能があってもいいかもしれない。
いずれにせよ,まずは既存の検索語変換交度を whr_kw() にまとめる作業から始めることになるだろう。
whr_kw()
}