Re: Ideas about a better API for postgres_fdw remote estimates

On Mon, Aug 31, 2020 at 01:53:01PM -0400, Tom Lane wrote:
> Stephen Frost <sfrost(at)snowman(dot)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.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee