| From: | Eric Ridge <eebbrr(at)gmail(dot)com> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: pg18 bug? SELECT query doesn't work |
| Date: | 2026-01-06 18:10:40 |
| Message-ID: | 9A42D802-5994-4DAF-86FB-AB5954840216@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
> On Jan 6, 2026, at 12:00 PM, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Eric Ridge | 2026-01-06 18:28:27 | Re: pg18 bug? SELECT query doesn't work |
| Previous Message | David G. Johnston | 2026-01-06 17:00:29 | Re: pg18 bug? SELECT query doesn't work |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Eric Ridge | 2026-01-06 18:28:27 | Re: pg18 bug? SELECT query doesn't work |
| Previous Message | Marcos Magueta | 2026-01-06 18:03:15 | Re: WIP - xmlvalidate implementation from TODO list |