On Mon, Feb 02, 2026 at 10:34:14PM -0500, Corey Huinker wrote:
> I'd have no issue including the expr definition in the existing object
> container - an optional parameter that allow (no warning) but which has no
> effect. We could then compare that optional parameter against the text
> representation of the node and issue a non-failing warning on any
> differences.
Well, you are making me doubt that relying on the expression text is a
good idea at all, so your argument regarding its portability across
releases is winning. Let's really add a negative attnum built based
on the position of the expressions in pg_stats_ext.exprs, though.
This should also lead to better error messages on restore depending on
the expression data we expect (I'll check ANALYZE about the
possibility of partial generation of the expression stats data
tomorrow or so).
> But in a way we're already getting this type checking if the expressions
> have different datatypes and either of them have most_common_values,
> histogram_bounds, or most_common_elems - as all of those require input
> coersion of the array values to datatypes of the expressions, and any
> failure in any of those dooms the whole exprs array.
Yeah, but that does not help if two expressions use the same types,
which is possible. On the contrary, that sounds kind of confusing
to rely on for this portion of the statext data to restore.
--
Michael
