Re: Potential partition pruning regression on PostgreSQL 18

On Thu, Apr 2, 2026 at 4:34 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> Attached is a draft patch for the fix.
>
> Regarding backpatching, I'm inclined to only back-patch this down to
> v18. This issue actually predates v18, for example, when the
> partition key is a non-Var expression. A non-Var target item will be
> wrapped in a PHV, causing us to fail the partition key match.
> However, the changes in v18 seem to have made the issue common enough
> to notice. This is very similar to the index matching case.

Here are the more formal patches for HEAD and for v18.

In the HEAD patch, I renamed strip_phvs_in_index_operand() to
strip_noop_phvs() and moved it from indxpath.c to placeholder.c, since
it is now a general-purpose utility used by both index matching and
partition pruning code.

However, since strip_phvs_in_index_operand() is an extern function
declared in a public header, I'm worried that third-party extensions
may have started calling it after it was introduced in ad66f705f. So
for the v18 back-patch, I retained strip_phvs_in_index_operand() in
indxpath.c as a thin wrapper around the new strip_noop_phvs(), to
avoid breaking such extensions in a minor release.

Does this seem like reasonable caution, or is it overkill given how
recently the function was introduced?

- Richard