Re: [[BUG] pg_stat_statements crashes with var and non-var expressions in IN clause

From: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Sami Imseih <samimseih(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [[BUG] pg_stat_statements crashes with var and non-var expressions in IN clause
Date: 2026-01-19 09:24:41
Message-ID: chqyxyhptywmynhcwfqcjpsj6ef2mqcgrd76f4ze2wgob6iurm@jkd6vfdvwkkv
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Mon, Jan 19, 2026 at 05:14:46PM +0900, Michael Paquier wrote:
> On Thu, Jan 15, 2026 at 02:53:20PM -0600, Sami Imseih wrote:
> >> As far as I recall it was an
> >> intentional design decision, and to adjust newa->list_end in such
> >> scenarios we need to solve the original problem of finding an end
> >> location of any arbitrary expression,
> >
> > I'm not sure I follow. How would we adjust newa->list_end?
>
> I may be missing something, of course, but Dmitry's message reads as
> follows to me:
> "It was a design choice to track the start and end locations because
> we needed that for arrays, and resetting the locations if we have Vars
> in the list like you are suggesting is OK by me."

Yep, I concur the current approach is fine. What I was saying about
adjusting newa->list_end is just an ideal and at the moment only
hypothetical scenario, where we could deduce end location of the new
list based on its nested elements. Currently there are no mechanism to
achieve that, so maybe in the future.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message lakshmi 2026-01-19 09:25:43 Re: parallel data loading for pgbench -i
Previous Message vignesh C 2026-01-19 09:24:34 Re: Logical Replication of sequences