Re: Regexp matching: bug or operator error? - Mailing list pgsql-general
From | Ken Tanzer |
---|---|
Subject | Re: Regexp matching: bug or operator error? |
Date | |
Msg-id | 41A4CAA5.2040908@desc.org Whole thread Raw |
In response to | Re: Regexp matching: bug or operator error? (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Regexp matching: bug or operator error?
|
List | pgsql-general |
Thanks for the quick responses yesterday. At a minimum, it seems like this behavior does not match what is described in the Postgres documentation (more detail below). But I still have a hard time understanding the results of these two queries: select SUBSTRING( 'X444X','.*?([0-9]{1,3}).*?'); This is the original query I submitted, with the puzzling non-greedy match. It returns '4'. Adding start and end characters to the query, like so: select SUBSTRING( 'X444X','^.*?([0-9]{1,3}).*?$'); returns '444'. If the "whole RE" was being set non-greedy by the first ".*?", then shouldn't the subsequent "([0-9]{1,3})" also match non-greedily, returning a '4', with the last ".*?" then capturing the balance of "44X"? Either way, I'm not sure why the start and end characters would effect the rest of the match. In terms of the Postgres documentation, it definitely seems at odds with the observed behavior. Here's my attempts to explain why: a) select SUBSTRING( 'X444X','[0-9]{1,3}'); returns '444'. This suggests that a "default" for the {m,n} syntax is greedy. b) Table 9-13 of the docs describes {m,n} syntax, then lists {m,n}? as a "non-greedy" version of the same. That, and the fact that there doesn't seem to be a specific "greedy" modifier, would both also imply that {m,n} should be greedy. Section 9.6.3.5: "A quantified atom with other normal quantifiers (including {m,n} with m equal to n) prefers longest match" I can't find anything else in this section that would say otherwise. I specifically can't find anything that says the whole expression becomes greedy or not. If the regex code isn't going to change, it seems that changing the documentation would be very helpful to avoid confusion. Of course, that's easy for me to say, since I wouldn't have to do the work! For that matter, I'd be willing to try editing the documentation, but I'd have to understand what the actual behavior is before I could try to describe it! :) Either way, thanks for the great DB program! Ken Tanzer p.s., The suggested regex rewrites some people responded with were appreciated, but the regex I used was just a simplified example for this posting. Here's the actual regex we're working on--any help reformulating this would be great! select substring('Searching for log 5376, referenced in this text' FROM '(?i)(?:.*?)logs?(?:\\s|\\n|<br>|<br />| )(?:entry|no|number|#)?(?:\\s|\\n|<br>|<br /> )?([0-9]{1,7})(.*?)'); We were able to get this to work by adding start and end characters, like so, but it doesn't seem like it should be necessary: select substring('Searching for log 5376, referenced in this text' FROM '(?i)^(?:.*?)logs?(?:\\s|\\n|<br>|<br />| )(?:entry|no|number|#)?(?:\\s|\\n\<br>|<br /> )?([0-9]{1,7})(.*?)$'); Tom Lane wrote: >Checking in the Tcl bug tracker reveals that this is an open issue >for them as well: > >http://sourceforge.net/tracker/index.php?func=detail&aid=219219&group_id=10894&atid=110894 >http://sourceforge.net/tracker/index.php?func=detail&aid=219358&group_id=10894&atid=110894 > >The first entry has Henry Spencer claiming that it is operating as >designed, but the second one seems to cast doubt on that claim. >In any case I tend to agree that the notation implies that greediness >should be an independent property of each quantifier. > >However, if Henry can't or doesn't want to fix it, I'm not sure that >I care to wade in ;-) > > regards, tom lane > >
Attachment
pgsql-general by date: