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 →
  1. Fix PQescapeLiteral()/PQescapeIdentifier() length handling