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

From Dmitry Dolgov
Subject Re: [[BUG] pg_stat_statements crashes with var and non-var expressions in IN clause
Date
Msg-id chqyxyhptywmynhcwfqcjpsj6ef2mqcgrd76f4ze2wgob6iurm@jkd6vfdvwkkv
Whole thread Raw
In response to Re: [[BUG] pg_stat_statements crashes with var and non-var expressions in IN clause  (Michael Paquier <michael@paquier.xyz>)
Responses Re: [[BUG] pg_stat_statements crashes with var and non-var expressions in IN clause
List 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.



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Logical Replication of sequences
Next
From: lakshmi
Date:
Subject: Re: parallel data loading for pgbench -i