␀ ␁ ␂ ␃ ␄ ␅ ␆ ␇ ␈ ␉ ␊ ␋
␌ ␍ ␎ ␏ ␐ ␑ ␒ ␓ ␔ ␕ ␖ ␗
␘ ␙ ␚ ␛ ␜ ␝ ␞ ␟ ␡
{希哲17年7月22日の日記 K#F85E/0758-ABDB}
宇田川浩行elog()
}{PostgreSQL の外充て手続き}{外充て函数}{制御}{トランザクション}(6){PostgreSQL の外充て函数 K#F85E/5B28-DDF9}
宇田川浩行通常,全体が1トランザクションとして扱われる。
内部でトランザクションの細かい制御は出来なかったが,専用函数が追加された。それ以前でも,elog()
などを使ってトランザクションの破棄は出来るほか,異常終了でも破棄される。
{希哲16年4月7日10歩 K#F85E/E74C-B300}
宇田川浩行2月23日頃から検索結果の改良について本格的に考え始めていたが,「検索属性」を導入し,検索結果の多段化を進めていくことにした。
現状,例えば括弧類を自動付加した検索は出来るが,その逆は出来ない。括弧付きで描出したい場合,括弧無しで検索して既存輪郭が無いことを確認した後,括弧を付けて再検索するということが多く,とりあえずこの手間を無くしたかった。全知検索演算子の制御に任意の括弧類を使えると好都合ということもあった。
文字数の昇順で揃えてそれなりの結果になっているのでこれを降順にすればいいかと思ったが,上手く行かない場面が多々あるので一時凌ぎの域を出ない。
将来的な拡張性も考えると検索結果の多段化が好ましい。風船輪郭や輪括内検索にも応用出来る。希哲14年7月30日8歩から輪括内検索は輪括内のみにすると使いにくいという理由で中途半端な状態になっていたが,優先表示で解決出来ることに気付いた。
整数値に揃えを兼ねた役割を与え,これを「検索属性」として利用出来るようにする。
ここまでは良いが,効率的な実装が難しい。単純に全ての検索パターンを UNION
で結合すればひどいことになるのは目に見えている。外充て函数で余計な検索を省くようにする,挿入・更新時に確定出来る情報はフラグ化しておくといったことに加えて,後縁での出力は最低限にして前縁で追加取得するといった工夫が必要になるかもしれない。
いずれにせよ後縁の対応は進めて問題ないだろう。設計方針さえ固まれば最適化はどうとでもなる。