Re: pg17.3 PQescapeIdentifier() ignores len
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Christoph Berg <myon@debian.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Justin Pryzby <pryzby@telsasoft.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-02-15T16:16:52Z
Lists: pgsql-hackers
Hi, On 2025-02-15 13:33:54 +0100, Christoph Berg wrote: > Re: Andres Freund > > > > The fprintf suggests that since 5dc1e42b4 PQescapeIdentifier ignores its len. > > > > > > Ugh, yes. Need something like the attached. > > > > I just pushed this fix, together with an expansion of test_escape.c. With the > > expanded test both uses of strlen() are detected. > > FTR, this is also caught by pygresql's regression tests: > > test_inserttable_with_dotted_table_name (tests.test_classic_connection.TestInserttable.test_inserttable_with_dotted_table_name) ... ERROR > > https://ci.debian.net/packages/p/pygresql/testing/amd64/57838998/ > https://qa.debian.org/excuses.php?package=postgresql-17 > > What's missing in the PG regression tests to see that problem? Well, the expanded tests added as part of the fix would catch it, but I agree, it's a problem this wasn't caught beforehand. I don't think that common uses of PQescapeIdentifier/Literal are likely to catch the problem, so it's perhaps not too surprising it wasn't caught. Which, I guess, shows that we really need more explicit edge-case coverage of at least the most crucial APIs (we barely have any). There's pretty much no way that pg_regress or TAP test style tests are going to catch a problem like this. Greetings, Andres Freund
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix PQescapeLiteral()/PQescapeIdentifier() length handling
- 1f7a05324524 13.20 landed
- 985908df1811 14.17 landed
- 22ffbbf24db4 15.12 landed
- 111f4dd273c8 16.8 landed
- a92db3d02dbd 17.4 landed
- efdadeb2238f 18.0 landed