> > IIRC, "variadic any" requires having at least one variadic parameter. > But that seems fine --- what would be the point, or even the > semantics, of calling pg_set_attribute_stats with no data fields? >
If my pg_dump run emitted a bunch of stats that could never be imported, I'd want to know. With silent failures, I don't. > Perhaps we could > invent a new backend function that extracts the actual element type > of a non-null anyarray argument. > A backend function that we can't guarantee exists on the source system. :( > Another way we could get to no-coercions is to stick with your > signature but declare the relevant parameters as anyarray instead of > text. I still think though that we'd be better off to leave the > parameter matching to runtime, so that we-don't-recognize-that-field > can be a warning not an error. > I'm a bit confused here. AFAIK we can't construct an anyarray in SQL: # select '{1,2,3}'::anyarray; ERROR: cannot accept a value of type anyarray > I think you missed my point: you're doing that inefficiently, > and maybe even with race conditions. Use the relcache's copy > of the pg_class row. > Roger Wilco. > Well, I'm here to debate it if you want, but I'll just note that *one* > error will be enough to abort a pg_upgrade entirely, and most users > these days get scared by errors during manual dump/restore too. So we > had better not be throwing errors except for cases that we don't think > pg_dump could ever emit. > 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.