I'm creating this new thread separate from the existing Statistics Export/Import thread to keep the original thread focused on that patch.
Assuming that the function signature for pg_set_attribute_stats() remains the same (regclass, attname, inherited, version, ...stats...), how would we design the function signature for pg_set_extended_stats()?
Currently, the variant arguments in pg_set_attribute_stats are mapping attribute names from pg_stats onto parameter names in the function, so a call looks like this:
SELECT pg_set_attribute_stats('public.foo'::regclass, 'foo_id', false, 17000,
'null_frac', 0.4::real,
'avg_width', 20::integer,
'n_distinct, ', 100::real,...);
And that works, because there's a 1:1 mapping of attribute names to param names in the pairs of variants.
However, that won't work for extended stats, as it has 2 mappings:
* 1 set of stats from pg_stats_ext
* N sets of stats from pg_stats_ext_exprs, one per expression contained in the statistics object definition.
My first attempt at making this possible is to have section markers. The variant arguments would be matched against column names in pg_stats_ext until the parameter 'expression' is encountered, at which point it would begin matching parameters from pg_stats_ext_exprs to parameters for the first expression. Any subsequent use of 'expression' would move the matching to the next expression.
This method places a burden on the caller to get all of the pg_stats_ext values specified before any expression values. It also places a burden on the reader that they have to count the number of times they see 'expression' used as a parameter, but it otherwise allows 1 variant list to serve two purposes.
Thoughts?
