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-15T17:07:21Z
Lists: pgsql-hackers
Hi, On 2025-02-15 17:55:12 +0100, Christoph Berg wrote: > Re: Andres Freund > > 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. > > What I can do is to trigger regression tests on all packages on > apt.postgresql.org after the minor releases have been built and then > raise any flags before the release goes out. I think that'd be *really* helpful. Of course that does require somebody watching and raising an alarm... Do you have ongoing package builds for sid or such? > Except that pygresql isn't yet a package on apt.pg.o... will fix that > now. This time, the problem was caught by Debian's CI machinery. Are there regular outomated rebuilds that could tell us of such a problem between the release being stamped and actually made? 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