Re: A really subtle lexer bug
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: pgsql-hackers@postgresql.org
Date: 2018-08-23T14:55:15Z
Lists: pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes: > "Andrew" == Andrew Gierth <andrew@tao11.riddles.org.uk> writes: > Andrew> I guess the fix is to extend the existing special case code > Andrew> that checks for one character left after removing trailing [+-] > Andrew> and also check for the two-character ops "<>" ">=" "<=" "=>" > Andrew> "!=". > Patch attached. > This fixes two bugs: first the mis-lexing of two-char ops as mentioned > originally; second, the O(N^3) lexing time of strings of - or + > characters is reduced to O(N^2) (in practice it's better than O(N^2) > once N gets large because the bison stack gets blown out, ending the > loop early). Looks reasonable offhand (didn't test). A couple of thoughts: * Some regression tests exercising these code paths might be a good thing. * There should likely be a comment near where EQUALS_GREATER and friends are defined, pointing out that if we add any more multi-character operators with special precedences, this code has to be taught about them. regards, tom lane
Commits
-
Fix lexing of standard multi-character operators in edge cases.
- d64fad666992 10.6 landed
- 5b4555f90c08 11.0 landed
- a40631a920ac 12.0 landed
- af988d13012f 9.5.15 landed
- 5ec70a928621 9.6.11 landed