Re: BUG #19849: queries fail after ANALYZE with expression stats on arrays

On Mon, Nov 09, 2026 at 06:09:19PM -0500, shihao zhong wrote:
> Thanks, Tom. The refactor turned out to be small. The code that fills
> in the pg_statistic columns can move into one function in analyze.c,
> and both places call it.

v3-0003's code cut looks tempting. That would have prevented the
original issue.

@@ -2333,12 +2333,7 @@ build_expr_data(List *exprs, int stattarget)
values[Anum_pg_statistic_starelid - 1] = ObjectIdGetDatum(InvalidOid);
values[Anum_pg_statistic_staattnum - 1] = Int16GetDatum(InvalidAttrNumber);
values[Anum_pg_statistic_stainherit - 1] = BoolGetDatum(false);
[...]
@@ -1764,79 +1843,15 @@ update_attstats(Oid relid, bool inh, int natts, VacAttrStats **vacattrstats)
values[Anum_pg_statistic_starelid - 1] = ObjectIdGetDatum(relid);
values[Anum_pg_statistic_staattnum - 1] = Int16GetDatum(stats->tupattnum);
values[Anum_pg_statistic_stainherit - 1] = BoolGetDatum(inh);

These two could also be passed down as arguments of your new
fill_attstats_values(), filling them within the routine instead of
letting the two callers do it.

+ * values[] and nulls[] must have room for Natts_pg_statistic entries. All

One thing that always stresses me with this kind of assumption is that
an error means an out-of-bound write, and a CVE. Here, we could also
use a palloc0'ed area worth Natts_pg_statistic, instead of expecting
the caller to do the right thing. The ANALYZE and expression stats
code paths are not performance-critical. Or ubsan would just catch
any problems?
--
Michael