From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Christoph Berg <myon(at)debian(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pg17.3 PQescapeIdentifier() ignores len |
Date: | 2025-02-15 17:07:21 |
Message-ID: | yexwfhicgqrwydmlcjmj6esptxlrghrruqmklrc2k5idg5tre7@j4re2mxtgicn |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Berg | 2025-02-15 17:22:49 | Re: pg17.3 PQescapeIdentifier() ignores len |
Previous Message | Tom Lane | 2025-02-15 16:57:40 | Re: New buildfarm animals with FIPS mode enabled |