> 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
