Re: pgsql: Reduce "Var IS [NOT] NULL" quals during constant folding

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Richard Guo <rguo(at)postgresql(dot)org>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgsql: Reduce "Var IS [NOT] NULL" quals during constant folding
Date: 2026-10-06 15:53:16
Message-ID: CA+TgmoZy22d8Mz3z_Sjj+cb6tJQyfe=fJT-XkWmFX2eGD067iw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Mon, Jul 21, 2025 at 10:23 PM Richard Guo <rguo(at)postgresql(dot)org> wrote:
> Reduce "Var IS [NOT] NULL" quals during constant folding

I feel like this commit message might have missed a fairly important
point here, which is that this commit made it necessary, in some set
of circumstances, for eval_const_expressions() to happen with a valid
PlannerInfo *root and with varnos already fixed. In addition to the
cases covered by 317c117d6d2 and c925ad30b04, there seems to be issues
with partition keys and partition constraints: see
set_baserel_partition_key_exprs and set_baserel_partition_constraint.
Attached are a pair of Claude-written test case that demonstrate
partition pruning failing as a result.

I'm afraid this isn't going to be all the bugs. We have expression
trees in a lot of places, and we call eval_const_expressions()
directly or indirectly in a lot of places, and it doesn't seem easy to
know what we might still have missed.

--
Robert Haas
Databricks

Attachment Content-Type Size
finding6.sql application/octet-stream 291 bytes
finding8.sql application/octet-stream 478 bytes

In response to

Browse pgsql-committers by date

  From Date Subject
Previous Message Robert Haas 2026-10-06 14:49:45 Re: pgsql: Teach expr_is_nonnullable() to handle more expression types

Browse pgsql-hackers by date

  From Date Subject
Previous Message Fujii Masao 2026-10-06 15:40:53 Re: remote_apply commit hangs when wal_receiver_status_interval = 0