Giving the parameter lists more thought, the desire for a return code more granular than true/false/null, and the likelihood that each function will inevitably get more parameters both stats and non-stats, I'm proposing the following:
Two functions:
pg_set_relation_stats(
out schemaname name,
out relname name,
out row_written boolean,
out params_rejected text[],
kwargs any[]) RETURNS RECORD
and
pg_set_attribute_stats(
out schemaname name,
out relname name,
out inherited bool,
out row_written boolean,
out params_accepted text[],
out params_rejected text[],
kwargs any[]) RETURNS RECORD
The leading OUT parameters tell us the rel/attribute/inh affected (if any), and which params had to be rejected for whatever reason. The kwargs is the variadic key-value pairs that we were using for all stat functions, but now we will be using it for all parameters, both statistics and control, the control parameters will be:
relation - the oid of the relation
attname - the attribute name (does not apply for relstats)
inherited - true false for attribute stats, defaults false, does not apply for relstats
warnings, boolean, if supplied AND set to true, then all ERROR that can be stepped down to WARNINGS will be. This is "binary upgrade mode".
version - the numeric version (a la PG_VERSION_NUM) of the statistics given. If NULL or omitted assume current PG_VERSION_NUM of server.
actual stats columns.
This allows casual users to set only the params they want for their needs, and get proper errors, while pg_upgrade can set
'warnings', 'true', 'version', 120034
and get the upgrade behavior we need.
and pg_set_attribute_stats.
pg_set_relation_stats(out schemaname name, out relname name,, out row_written boolean, out params_entered int, out params_accepted int, kwargs any[])
