Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

regcomp.c

Blame
    • Tom Lane's avatar
      a43b4ab1
      Fix enforcement of restrictions inside regexp lookaround constraints. · a43b4ab1
      Tom Lane authored
      Lookahead and lookbehind constraints aren't allowed to contain backrefs,
      and parentheses within them are always considered non-capturing.  Or so
      says the manual.  But the regexp parser forgot about these rules once
      inside a parenthesized subexpression, so that constructs like (\w)(?=(\1))
      were accepted (but then not correctly executed --- a case like this acted
      like (\w)(?=\w), without any enforcement that the two \w's match the same
      text).  And in (?=((foo))) the innermost parentheses would be counted as
      capturing parentheses, though no text would ever be captured for them.
      
      To fix, properly pass down the "type" argument to the recursive invocation
      of parse().
      
      Back-patch to all supported branches; it was agreed that silent
      misexecution of such patterns is worse than throwing an error, even though
      new errors in minor releases are generally not desirable.
      a43b4ab1
      History
      Fix enforcement of restrictions inside regexp lookaround constraints.
      Tom Lane authored
      Lookahead and lookbehind constraints aren't allowed to contain backrefs,
      and parentheses within them are always considered non-capturing.  Or so
      says the manual.  But the regexp parser forgot about these rules once
      inside a parenthesized subexpression, so that constructs like (\w)(?=(\1))
      were accepted (but then not correctly executed --- a case like this acted
      like (\w)(?=\w), without any enforcement that the two \w's match the same
      text).  And in (?=((foo))) the innermost parentheses would be counted as
      capturing parentheses, though no text would ever be captured for them.
      
      To fix, properly pass down the "type" argument to the recursive invocation
      of parse().
      
      Back-patch to all supported branches; it was agreed that silent
      misexecution of such patterns is worse than throwing an error, even though
      new errors in minor releases are generally not desirable.