diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2021-01-08 12:16:00 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2021-01-08 12:16:00 -0500 |
commit | 8354371d0a539c0da9fcca4e4341872db60860e1 (patch) | |
tree | d005bfecb39ee604aad33d854109094cf7ac2229 /src/backend/executor/nodeWorktablescan.c | |
parent | 29556bf1be91510ba282e02f3ec890c3b6bf4f94 (diff) | |
download | postgresql-8354371d0a539c0da9fcca4e4341872db60860e1.tar.gz postgresql-8354371d0a539c0da9fcca4e4341872db60860e1.zip |
Fix ancient bug in parsing of BRE-mode regular expressions.
brenext(), when parsing a '*' quantifier, forgot to return any "value"
for the token; per the equivalent case in next(), it should return
value 1 to indicate that greedy rather than non-greedy behavior is
wanted. The result is that the compiled regexp could behave like 'x*?'
rather than the intended 'x*', if we were unlucky enough to have
a zero in v->nextvalue at this point. That seems to happen with some
reliability if we have '.*' at the beginning of a BRE-mode regexp,
although that depends on the initial contents of a stack-allocated
struct, so it's not guaranteed to fail.
Found by Alexander Lakhin using valgrind testing. This bug seems
to be aboriginal in Spencer's code, so back-patch all the way.
Discussion: https://postgr.es/m/16814-6c5e3edd2bdf0d50@postgresql.org
Diffstat (limited to 'src/backend/executor/nodeWorktablescan.c')
0 files changed, 0 insertions, 0 deletions