0

誰かが PostgreSQL 9.2.4でのこの奇妙な動作を説明できますかregexp_matches()(9.1.9 でも同じ結果):

db=# SELECT regexp_matches('test string', '$') AS end_of_string;
 end_of_string
---------------
 {""}
(1 row)

db=# SELECT regexp_matches('test string', '$', 'g') AS end_of_string;
 end_of_string
---------------
 {""}
 {""}
(2 rows)

-> SQLfiddle デモ。

2 番目のパラメーターは正規表現です。$文字列の終わりを示します。
3 番目のパラメーターはフラグ用です。gは「グローバル」用です。つまり、関数は最初の一致で停止しません。

この関数は、フラグを使用して文字列の末尾を2 回報告しているように見えますが、定義ごとに 1回しgか存在できません。それは私のクエリを壊します。:( 何か不足していますか？

可能な文字列について、クエリが最後にもう 1行を返す必要があります。このクエリでうまくいくと思っていましたが、次の2 つの行が追加されます。

SELECT (regexp_matches('test & foo/bar', '(&|/|$)', 'ig'))[1] AS delim

行を手動で追加する方法は知っていますが、関数に処理させたいです。

4

4 に答える 4

1

たとえば、最近同じ問題が発生したC＃でも同じことが発生するため、これは正規表現の通常の動作だと思います

これは$、特定の記号ではなく特定の位置を表すため、$実際には何にも一致せず、パーサーの位置が同じ位置に留まるためです。

規則を少し変更する必要があります。

使用できる空の文字列をテストするには^$

于 2014-01-11T17:55:59.940 に答える
1

PostgreSQL のバグだったようです。9.3.8で修正されていることを確認しました。リリースノートを見ると、次の場所に参考文献がある可能性があります。

9.3.4

  • 正規表現演算子がクエリキャンセルリクエストによって早期に終了できるようになりました。 (Tom Lane)

    これにより、異常な正規表現によってサーバー プロセスが長時間にわたって中断されずにロックされるシナリオを回避できます。

9.3.6

  • 正規表現の最短順一致の誤った検索が修正されました。 (Tom Lane)

    許容される反復回数が ? によって制限されている場合、マッチングはしばしば失敗します。量指定子またはバインドされた式。

9.3.x に絞り込んでくれた Erwin に感謝します。

于 2016-06-24T13:16:13.637 に答える
0

これは、Postgres 9.3 で修正されたバグです。受け入れられた回答を参照してください。

Postgres 9.2 以前の場合: 私の状況の中途半端な回避策は、.$代わりに式を使用することです。最後の文字で任意の文字列に 1 回一致します。

WITH x(id, t) AS (
   VALUES
    (1, 'test & foo/bar')
   ,(2, 'test')
   ,(3, '')            -- empty string
   ,(4, 'test & foo/') -- other branch as last character
   )
SELECT id, (regexp_matches(t, '(&|/|.$)', 'ig'))[1] AS delim
FROM   x;

ただし、空の文字列では失敗します。
そして、最後の文字がたまたま別のブランチと一致すると失敗します。のように: 'foo/bar/'。
そして、実際の最終キャラクターを戻すのは完璧ではありません。空の文字列の方がはるかに望ましいでしょう。

-> SQLフィドル。

于 2013-08-12T14:58:40.113 に答える