Re: statatt_build_stavalues->LOCAL_FCINFO wrong number - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: statatt_build_stavalues->LOCAL_FCINFO wrong number
Date
Msg-id akIrjdIIRViUT2o3@paquier.xyz
Whole thread
List pgsql-hackers
On Sat, Jun 27, 2026 at 01:25:39PM +0800, jian he wrote:
> That mistake is harmless now, but if somebody use
> LOCAL_FCINFO(fcinfo, 1), then it may have potential problems.
> So let's try to use InputFunctionCallSafe instead, see attached.

It's an overallocation, harmless still incorrect.  This also exists on
REL_18_STABLE; this code has been moved on HEAD to its current
location from atttribute_stats.c.

> I found this while trying to use InputFunctionCallSafe inside array_in_safe.
> Should we consider fully refactoring array_in_safe to use it too?

Yep, let's do this cleanup in array_in_safe() as well.  I was
wondering about doing that only once v20 opens up, but array_in_safe()
is new in v19.  So let's just make the code right now rather than
create an inconsistency before v19 gets released.

Thanks for the report.  Will do something for both spots.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Report oldest xmin source when autovacuum cannot remove tuples
Next
From: Tender Wang
Date:
Subject: Re: Fix HAVING-to-WHERE pushdown with mismatched operator families