> > It seems to me that this comes down to the text[] representation when > we read this data from the catalogs, where we can just rely on NULL > being in the value, and the official marker in this case: > https://www.postgresql.org/docs/current/arrays.html#ARRAYS-INPUT
And we're doing a lot of casting ANYARRAY to text throughout this and the attribute stats, so that our assurance that we can live without nulls. Perhaps we have a couple of specific cases where checking for we want > some NULL-ness knowledge? It would be less expensive than a full > array deconstruction, for sure, especially if the MCVs are large text > values. > It's a good theory, or maybe the original coder just assumed that the caller of pg_mcv_list() SRF could lateral-unnest the output and keep only the interesting columns. Rebasing and null-rip-out underway.
