| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | srn(at)coolheads(dot)com |
| Cc: | pgsql-docs(at)postgresql(dot)org |
| Subject: | Re: can't be both non-capturing and still capture |
| Date: | 2017-07-04 02:10:03 |
| Message-ID: | 25895.1499134203@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-docs |
srn(at)coolheads(dot)com writes:
> Here, the whole regexp is non-capturing, right, so how can the result be
> reported as shown?
No, the outer parens are non-capturing, but the ones inside them still
are capturing parens.
Perhaps it would clarify matters if you tried it with plain outer parens:
=# SELECT regexp_matches('abc01234xyz', '((.*?)(\d+)(.*)){1,1}');
regexp_matches
-----------------------------
{abc01234xyz,abc,01234,xyz}
(1 row)
In this case we get a report from each of the four sets of capturing
parens. Or another example:
=# SELECT regexp_matches('abc01234xyz', '((?:.*?)(\d+)(.*)){1,1}');
regexp_matches
-------------------------
{abc01234xyz,01234,xyz}
(1 row)
Outer parens capture, first inner set don't, other two inner sets do.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | rdm | 2017-07-07 18:34:53 | extraneous spaces after links |
| Previous Message | Michael Paquier | 2017-07-03 22:43:32 | Re: Documentation still mentioning SSLv2 and SSLv3 |