Re: regexp_matches() quantified-capturing-parentheses oddity
От | Harald Fuchs |
---|---|
Тема | Re: regexp_matches() quantified-capturing-parentheses oddity |
Дата | |
Msg-id | puk4wx9wjf.fsf@srv.protecting.net обсуждение исходный текст |
Ответ на | regexp_matches() quantified-capturing-parentheses oddity (Julian Mehnle <julian@mehnle.net>) |
Ответы |
Re: regexp_matches() quantified-capturing-parentheses oddity
|
Список | pgsql-general |
In article <13289.1260290974@sss.pgh.pa.us>, Tom Lane <tgl@sss.pgh.pa.us> writes: > Julian Mehnle <julian@mehnle.net> writes: >> So far, so good. However, can someone please explain the following to me? >> wisu-dev=# SELECT regexp_matches('quux@foo@bar.zip', '([@.]|[^@.]+)+', 'g'); >> wisu-dev=# SELECT regexp_matches('quux@foo@bar.zip', '([@.]|[^@.]+){1,2}', 'g'); >> wisu-dev=# SELECT regexp_matches('quux@foo@bar.zip', '([@.]|[^@.]+){1,3}', 'g'); > These might be a bug, but the behavior doesn't seem to me that it'd be > terribly well defined in any case. The function should be pulling the > match to the parenthesized subexpression, but here that subexpression > has got multiple matches --- which one would you expect to get? Perl seems to return always the last one, but the last one is never just 'p' - so I also think that Julian has spotted a bug.
В списке pgsql-general по дате отправления: