On Thu, May 28, 2026 at 05:11:42PM +0000, Tristan Partin wrote: > Can you share how someone might use this additional information? > > Not sure I understand why we would want to expose the existence of the > callbacks to make assertions at the SQL level. I see that in > pgstat_register_kind(), we have the following code: > > We could extend these invariant checks to make sure that the callbacks > are only set when fixed_amount is true for instance. I am very much open > to having my mind changed.
There is currently no internal mechanism to make sure that the built-in stats kinds have a consistent setup in terms of flags and callbacks set, so for developers we could immediately complain when generating patches that add new stats kinds. For custom stats kinds, loaded libraries could have more cross-checks. Perhaps it is not worth bothering at the end, and I'd be fine to keep the data published as minimal as you see fit. Still, fixed_amount, write_to_file and accessed_across_databases feel like useful additions. If we keep shared_size, it may make sense to set it to NULL if we don't know about it? That's the case of the built-in fixed-sized stats kinds. We set the value for custom fixed-sized stats kinds. -- Michael
signature.asc
Description: PGP signature
