Re: Ideas about a better API for postgres_fdw remote estimates - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Ideas about a better API for postgres_fdw remote estimates
Date
Msg-id 4118983.1598896381@sss.pgh.pa.us
Whole thread Raw
In response to Re: Ideas about a better API for postgres_fdw remote estimates  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Stephen Frost <sfrost@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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior
Next
From: Ranier Vilela
Date:
Subject: Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior