On Fri, Jan 30, 2026 at 12:08:49AM -0500, Corey Huinker wrote:
> 3. Keeping the 2-D text array in #1, but each "row" is a list of
> kwargs-like pairs like the arguments used in pg_restore_attribute_stats
> (i.e. ARRAY['null_frac','0.5','avg_width','1.0','most_common_values',...]
> 
> 4. JSON. The outer structure would be an array of objects, each object
> would be a key-value.

I'd still favor 4 on the ground that it's easier to edit and read,
which would more in line with the MCV, dependencies, ndistinct and
att/rel statistics.  The format proposed in the attached patch is hard
to work with, anyway.  Now, I do take your point about composite
record values casted into a single text value could be confusing
(double-quote issues, I guess?), so perhaps a text[] as in 3 would be
more adapted for readability.  We could also force some checks based
the order of the arguments in the input array, so as duplicates are
not an issue, I guess? 

Structurally, I feel that import_expressions() is overcomplicated, and
with the correct structure tracking the state of each field, I would
try to reduce a bit the duplication that the patch presents, aiming at
less callers of statatt_build_stavalues() and statatt_set_slot(),
perhaps.

I have also posted a few more arguments here, for reference:
https://www.postgresql.org/message-id/[email protected]
--
Michael

Attachment: signature.asc
Description: PGP signature

Reply via email to