Ticket UUID: | 884d0ac78cbab248d054ec96d13c2a741bb0a94c | |||
Title: | Unexpected string-start constraint match in middle of string after newline | |||
Type: | Bug | Version: | core-8-6-branch tip, 28-Dec-2017 | |
Submitter: | dkf | Created on: | 2017-12-28 00:52:02 | |
Subsystem: | 43. Regexp | Assigned To: | nobody | |
Priority: | 5 Medium | Severity: | Minor | |
Status: | Open | Last Modified: | 2021-02-20 21:37:20 | |
Resolution: | None | Closed By: | nobody | |
Closed on: | ||||
Description: |
(text/html)
If you do: <pre> regexp -all {^|\n} "foo\nbar" </pre> then it returns <tt>3</tt>. I'd expect that (perhaps) with the <tt>-line</tt> option, but in standard mode that is rather "surprising" as there is only one place where the string starts and only one newline character. | |||
User Comments: |
tgl added on 2021-02-20 21:37:20:
FWIW, I can't reproduce this misbehavior in current Postgres: I get a correct-looking result from # select regexp_replace(E'foo\nbar', '^|\n', E'\nXX', 'g'); regexp_replace ---------------- + XXfoo + XXbar (1 row) I speculate that it got fixed as a side-effect of the constraint loop fixes we did awhile ago. I thought you guys had absorbed those, though. dkf added on 2017-12-28 12:47:54: (text/html) A consequence of this issue is <a href="https://stackoverflow.com/q/47995488/301832">this</a>: <pre> % puts [regsub -all "^|\n" "foo\nbar" "\nXX"] XXfoo XX XXbar </pre> The double substitution of <tt>\nXX</tt> before <tt>bar</tt> is again "unexpected". |