I don't think that's correct. I'm pretty sure spaces after the comma are possible.

I thought so. What do you think is a better solution for this? I suggest moving this to PL2 until a fix is found.

We need to properly analyse what punctuation-hexnumbers is supposed to match. It looks like something like select a, b '... but I don't understand the role of the hexadecimal and parenthesis. The a-f doesn't even make much sense, since hexadecimals must be preceded by either X' or 0x in MySQL. I have the feeling that we might be able to split up the character class into a more restrictive sequence, which would fix the issue.

If you check the regex, all of the below statements are exact matches.

SELECT * FROM users WHERE name = 'admin', --


SELECT * FROM users WHERE username = 'admin', '1'='1'


INSERT INTO logs (ip, comment) VALUES ('192.168.0.1', 'test')


SELECT * FROM data WHERE hash = 'abc', 0x1a


SELECT * FROM orders WHERE product = 'item', (5)

The fourth statement above provides a hexadecimal syntax usage.

Thanks. So the main issue appears to be that the regex doesn't match quotes. We could expand the regex with three additional expressions that match every type of quote, e.g.,

...'[^']*'...|..."[^"]*"...|...`[^`]*`...

Making quotes optional would lead to the same FP as above.

No, I mean matching quote pairs. To do that, you need one expression per quote type. Currently, punctuation-hexnumbers is paired with ticks but that doesn't work as it's supposed to, I believe. punctuation-hexnumbers may not have match a quote, but a letter, so ticks will not match a closing quote but an opening one. If we matched quote pairs, we could reduce FPs. Although it's common enough in french to have a name with more than one quote, e.g., rue d'Arlon sur l'avon, so that would still remain an FP.

Honestly, I think the regex is just too generic. It's combined with detection for SQL keywords, which doesn't make much sense. The quote detection stuff is clearly more prone to FPs and should live in a separate rule. Could you modify the PR to split the rule into two distinct rules? That will also make it easier to test different detections.

That makes sense, separating based on quote pairs will surely reduce FP, since the phrase like rue d'Arlon uses single quotes.

Fixed the issue. Actually the regex was wrong, and we were matching {{ticks}} after {{ticks}} which is not correct.

I don't agree with your latest change, but I'll need some time to look into it properly.