Re: pg18 bug? SELECT query doesn't work
Eric Ridge <eebbrr@gmail.com>
From: Eric Ridge <eebbrr@gmail.com>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: pgsql-general <pgsql-general@postgresql.org>
Date: 2026-01-06T18:10:40Z
Lists: pgsql-hackers, pgsql-general
> On Jan 6, 2026, at 12:00 PM, David G. Johnston <david.g.johnston@gmail.com> wrote: > > While I haven't dug into the actual specifics of this report in detail, the change in question happened back in v10. > > https://www.postgresql.org/docs/10/release-10.html Thanks. I wouldn't have thought to look back that far since the query worked on v15. Interesting. > The failure to emit an error when it probably should have is likely a bug in older versions since fixed. Fair enough. > That the behavior depends on the chosen plan and plans differ when you do and do not materialize a CTE is likewise not surprising. I guess I wouldn't expect Postgres to generate a plan that it then can't execute. That's what's surprising to me. But it's fine. In all my years of using Postgres this is the first time I've run into a query that no longer executes, so I wanted to bring it to y'alls attention. Thanks again! eric
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix unsafe pushdown of quals referencing grouping Vars
- 7650eabb662f 18.2 landed
- 34740b90bc12 19 (unreleased) landed
-
Introduce an RTE for the grouping step
- 247dea89f761 18.0 cited