Tom Lane fadff3fc94 Prevent mis-encoding of "trailing junk after numeric literal" errors. ... Since commit 2549f0661, we reject an identifier immediately following a numeric literal (without separating whitespace), because that risks ambiguity with hex/octal/binary integers. However, that patch used token patterns like "{integer}{ident_start}", which is problematic because {ident_start} matches only a single byte. If the first character after the integer is a multibyte character, this ends up with flex reporting an error message that includes a partial multibyte character. That can cause assorted bad-encoding problems downstream, both in the report to the client and in the postmaster log file. To fix, use {identifier} not {ident_start} in the "junk" token patterns, so that they will match complete multibyte characters. This seems generally better user experience quite aside from the encoding problem: for "123abc" the error message will now say that the error appeared at or near "123abc" instead of "123a". While at it, add some commentary about why these patterns exist and how they work. Report and patch by Karina Litskevich; review by Pavel Borisov. Back-patch to v15 where the problem came in. Discussion: https://postgr.es/m/CACiT8iZ_diop=0zJ7zuY3BXegJpkKK1Av-PU7xh0EDYHsa5+=g@mail.gmail.com		2024-09-05 12:42:33 -04:00
..
ecpg	Prevent mis-encoding of "trailing junk after numeric literal" errors.	2024-09-05 12:42:33 -04:00
libpq	Check availability of module injection_points in TAP tests	2024-09-05 13:29:43 +09:00
Makefile
meson.build	Update copyright for 2024	2024-01-03 20:49:05 -05:00