On Mon, Aug 31, 2020 at 05:46:22PM -0400, Bruce Momjian wrote: > On Mon, Aug 31, 2020 at 01:53:01PM -0400, Tom Lane wrote: > > Stephen Frost <sfr...@snowman.net> writes: > > > Feature work either requires changes to pg_dump, or not. I agree that > > > features which don't require pg_dump changes are definitionally less > > > work than features which do (presuming the rest of the feature is the > > > same in both cases) but that isn't a justification to not have pg_dump > > > support in cases where it's expected- we just don't currently expect it > > > for statistics (which is a rather odd exception when you consider that > > > nearly everything else that ends up in the catalog tables is included). > > > > > For my part, at least, I'd like to see us change that expectation, for a > > > number of reasons: > > > > Yeah. I think that originally we expected that the definition of the > > stats might change fast enough that porting them cross-version would be > > problematic. Subsequent experience has shown that they don't actually > > change any faster than any other aspect of the catalogs. So, while > > I do think we must have a plan for how to cope when/if the definition > > changes, I don't buy Bruce's argument that it's going to require more > > maintenance effort than any other part of the system does. > > Well, my point is that even bucket/calculation/data text respresentation > changes could affect dumping statistics, and that is kind of rare for > other changes we make.
And I have been hoping someone would prove me wrong all these years, but it hasn't happened yet. It is possible we have hit a tipping point where the work is worth it, and I hope that is the case. I am just explaining why I think it has not happened yet. -- Bruce Momjian <br...@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
