I think it'll be a serious, serious error for this not to be SECTION_DATA. Maybe POST_DATA is OK, but even that seems like an implementation compromise not "the way it ought to be".
We'd have to split them on account of when the underlying object is created. Index statistics would be SECTION_POST_DATA, and everything else would be SECTION_DATA. Looking ahead, statistics data for extended statistics objects would also be POST. That's not a big change, but my first attempt at that resulted in a bunch of unrelated grants dumping in the wrong section.
At the request of a few people, attached is an attempt to move stats to DATA/POST-DATA, and the TAP test failure that results from that.
The relevant errors are confusing, in that they all concern GRANT/REVOKE, and the fact that I made no changes to the TAP test itself.
$ grep 'not ok' build/meson-logs/testlog.txt not ok 9347 - section_data: should not dump GRANT INSERT(col1) ON TABLE test_second_table not ok 9348 - section_data: should not dump GRANT SELECT (proname ...) ON TABLE pg_proc TO public not ok 9349 - section_data: should not dump GRANT SELECT ON TABLE measurement not ok 9350 - section_data: should not dump GRANT SELECT ON TABLE measurement_y2006m2 not ok 9351 - section_data: should not dump GRANT SELECT ON TABLE test_table not ok 9379 - section_data: should not dump REVOKE SELECT ON TABLE pg_proc FROM public not ok 9788 - section_pre_data: should dump CREATE TABLE test_table not ok 9837 - section_pre_data: should dump GRANT INSERT(col1) ON TABLE test_second_table not ok 9838 - section_pre_data: should dump GRANT SELECT (proname ...) ON TABLE pg_proc TO public not ok 9839 - section_pre_data: should dump GRANT SELECT ON TABLE measurement not ok 9840 - section_pre_data: should dump GRANT SELECT ON TABLE measurement_y2006m2 not ok 9841 - section_pre_data: should dump GRANT SELECT ON TABLE test_table not ok 9869 - section_pre_data: should dump REVOKE SELECT ON TABLE pg_proc FROM public