Re: BUG #19715: pg_restore_attribute_stats() rejects range statistics for a domain over int4multirange

Hi,

Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> I'd certainly welcome more eyes here. Please note that this applies
> on HEAD cleanly, and should mostly apply cleanly on v19.

It applies with git am on both master (2c10c2ce4d7) and REL_19_STABLE
(2c5cd772b90), and make check passes on both. With only the test
changes of v2 and not the C ones, stats_import fails on master with
the expected warnings, so the new tests catch the bug.

I also checked the path users hit, pg_dump --statistics-only into a
database with the same schema, and compared every field of pg_stats
and pg_stats_ext_exprs before and after. The table has 17 columns and
the statistics object 8 expressions, the cases of the report plus a
few beyond the ones in the tests:

- a domain over a domain, for range, multirange and tsvector
- a domain over int4range with a CHECK constraint
- a domain over a range type with its own collation (text, "C")
- expressions of those types, next to one over a domain over int4[]

Results:

- master: 15 warnings. Range stats are lost for 6 domain columns,
including the nested, CHECK and collated ones, and MCELEM for the 2
tsvector domains. All 8 expressions lose all their stats.
- master + v2: no warnings, all 25 identical after the restore.
- REL_19_STABLE + v2: the same.
- REL_18_STABLE (66d1de70c84): the same 8 columns fail as on master.
I can run the same script on the v18 flavor when you post it.

A domain over int4[] and an array of a domain over int4 already come
through intact without the patch, in case that question comes up.

One thing outside this bug, about why all 8 expressions were lost.
import_expressions() stores a failed expression as NULL and keeps the
others, per its comments, but extended_statistics_update() then drops
the whole stxdexpr array when exprs_is_perfect is false. With one
statistics object on the d_arr expression plus a domain-over-range
one, master restores nothing for either; with the d_arr expression
next to a plain one, it is restored. Is dropping all of them
intended? I may be missing the reason. v2 removes the cause here,
so this only matters for other rejections.

The scripts and outputs are in the attachment.

Regards,
Manu