Invalid "trailing junk" error message when non-English letters are used
Karina Litskevich <litskevichkarina@gmail.com>
From: Karina Litskevich <litskevichkarina@gmail.com>
To: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-08-27T15:05:53Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Prevent mis-encoding of "trailing junk after numeric literal" errors.
- fadff3fc9459 18.0 landed
- f37ac613a835 15.9 landed
- 7dcbf0afa28c 17.0 landed
- 4fd4d7653e2c 16.5 landed
-
Reject trailing junk after numeric literals
- 2549f0661bd2 15.0 cited
Attachments
- v1-0001-Improve-error-message-for-rejecting-trailing-junk.patch (text/x-patch) patch v1-0001
Hi hackers, When error "trailing junk after numeric literal" occurs at a number followed by a symbol that is presented by more than one byte, that symbol in the error message is not displayed correctly. Instead of that symbol there is only its first byte. That makes the error message an invalid UTF-8 (or whatever encoding is set). The whole log file where this error message goes also becomes invalid. That could lead to problems with reading logs. You can see an invalid message by trying "SELECT 123ä;". Rejecting trailing junk after numeric literals was introduced in commit 2549f066 to prevent scanning a number immediately followed by an identifier without whitespace as number and identifier. All the tokens that made to catch such cases match a numeric literal and the next byte, and that is where the problem comes from. I thought that it could be fixed just by using tokens that match a numeric literal immediately followed by an identifier, not only one byte. This also improves error messages in cases with English letters. After these changes, for "SELECT 123abc;" the error message will say that the error appeared at or near "123abc" instead of "123a". I've attached the patch. Are there any pitfalls I can't see? It just keeps bothering me why wasn't it done from the beginning. Matching the whole identifier after a numeric literal just seems more obvious to me than matching its first byte. Best regards, Karina Litskevich Postgres Professional: http://postgrespro.com/