I believe you are referring to Tom's statement that "it'll be a serious, serious error for [stats] not to be SECTION_DATA". The statement is somewhat softened by the sentence that follows, and slightly more by [2]. But it's pretty clear that SECTION_POST_DATA is, at best, an implementation comprosmise.
The reason we need to put some stats in SECTION_POST_DATA is because of the hack to resolve MVs that depend on primary keys by moving the MV into SECTION_POST_DATA. (An MV can depend on a primary key when the query has a GROUP BY that relies on functional dependencies to be valid.) That's a fairly marginal case, and one we might be able to resolve a better way in the future, so I don't think that should drive the design.
I understand the benefits of having statistics on the underlying tables could aid the performance of the queries that populate the materialized views. What I struggle to understand is how that purpose isn't served better by statistics being in SECTION_NONE like COMMENTs are, so that they are imported immediately after the object that they reference.
Reagrding [2] and [3], we might need to reconsider the behavior of the --data-only option. I asked for the v38 behavior out of a sense of consistency and completeness (the ability to express whatever combination of things the user might want). But re-reading those messages, we might want --data-only to include the stats?
I think there's going to be some friction in the user's shift from thinking that they did want only data to realizing that they actually didn't want schema.
