That's not what I suggested at all. The function parameters would be declared anyarray, but the values passed to them would be coerced to the correct concrete array types. So as far as the coercion rules are concerned this'd be equivalent to the variadic-any approach.
+1
> That's pretty persuasive. It also means that we need to trap for error in > the array_in() calls, as that function does not yet have a _safe() mode.
Well, the approach I'm advocating for would have the array input and coercion done by the calling query before control ever reaches pg_set_attribute_stats, so that any incorrect-for-the-data-type values would result in hard errors. I think that's okay for the same reason you probably figured you didn't have to trap array_in: it's the fault of the originating pg_dump if it offers a value that doesn't coerce to the datatype it claims the value is of.