On Fri, Jan 23, 2026 at 2:46 PM Corey Huinker <[email protected]> wrote: >> >> How about the multirange range case in extended_statistics_update() >> for the mcv/expression path? > > > Added. > >> >> import_expressions() also complains about a statatt_set_slot() with >> histograms. > > > Unsure what you mean here. > >> >> These ones are less consistent in style, the error hints should be the >> errmsg, and there are some s/statitisics/statistics/. The errhint >> should be a full sentence, so I guess that you mean to switch both >> fields in such cases. > > > The 0003 patch of this set addresses this. > >> >> s/the the/the/, I think this one's mine. :D > > > 0002 > >> >> >> While the documentation shows one example with n_distinct, >> dependencies and exprs, I'd guess that we should push forward with >> something similar regarding most_common_val, most_common_val_nulls, >> most_common_freqs, most_common_base_freqs. It looks particularly >> important to expand this part, the relationship they have between each >> pther, their expected input format (?), and what they map to in the >> catalogs. If one is specified, all four of them are required, for >> example, but that's not the only thing I imagine should keep a track >> of. This data is more complex than the single stats fields. > > > I think some of this may have been addressed in this patchset. > > I've left these patches un-squashed to help differentiate what changes > address which problems. They'll likely be re-squashed once those issues are > addressed. > > The most interesting here is the change I did to statatt_get_type() to get it > to work for MCV/expression multiranges. Mostly, the problem arose from the > fact that MCVlist will have multirange as a part of the exported tuple text > array, so there is a legit need to parse the input of a multirange's text > reprepresentation, whereas with attribute stats we only ever need to parse > the input of the multirange's element, a plain old range. The fix, as you may > see highlights how statatt_get_type() is doing two things (resolving typ* > info for an attribute or expression, and fetching the basetype and basetype's > ltopr and eqopr) and maybe the basetype/operator stuff should be moved to its > own function. > > Another possible solution is to change the two refactor the > examine_attribute() functions (one in analyze.c, one in extended_stats.c) > unifying them where possible, and allowing the unified function to still > generate a VacAttrStats even if the attstattarget is 0. That's a heavier > lift, and I left things as they are now to demonstrate the issue at hand. > > Rebased as well. >
v30-0003-normalize-error-messages.patch introduced a typo: %s/incorect/incorrect -- Regards Junwang Zhao
