> That concern is exactly the reason why we never did this originally.
> In particular, emitting raw INSERTs into pg_statistic is just plain
> foolish; we have changed the rowtype of pg_statistic in the past and
> are likely to do so again. At a minimum we would need such a facility
> to be proof against addition of more statistic "slots" (more columns)
> to pg_statistic.
While this approach may indeed look dumb, it is intended to be used only in
conjunction with 'binary-upgrade' option, which effectively means that the
pg_dump-generated INSERT statement has to be compatible only with the release
that includes this very pg_dump version. Thus, there's no need for validation.
> And of course there was code to emit such a dump, producing one
> dump statement per occupied "slot" in pg_statistic plus one call to
> the other function per pg_statistic row.
> An API like this seems a good deal more future-proof than plain INSERTs.
This sounds really good, but I doubt that this is necessary if we're to just
preserve statistical data during an upgrade.
> Ideally, ordinary users
> could use this facility to transfer statistics for their own tables, just
> as they can use pg_dump ... but without adequate validity checking, it's
> way too much of a security hazard to allow that.
This could be implemented separately from the pg_dump if needed. The latter
proposal aims for the preservation of the statistical data during the database
upgrade, which is a rather important feature required by many DBAs. Of course,
it would be great if there was a way for a user to dump and restore stats for
his own tables on a whim, but, in my opinion, it is far less important.