pete...@gmx.net (Peter Eisentraut) writes: > On Fri, 2009-09-25 at 16:59 -0400, Tom Lane wrote: >> "shakahsha...@gmail.com" <shakahsha...@gmail.com> writes: >> > From pg_dump/pg_restore section (9.2 of the Todo page on the >> > PostgreSQL Wiki), is the following item >> > "Add comments to output indicating version of pg_dump and of the >> > database server" >> > simply asking for a change to the pg_dump header from: >> >> I think so, but what's not clear is whether this is a good idea to do >> in the default output. It might only be appropriate in "verbose" mode, >> so as not to introduce unnecessary diffs between logically identical >> dumps. > > Well, a diff of the same database made by different (major) versions of > pg_dump will already be different in most situations, so adding the > pg_dump version number in it is essentially free from this perspective. > > What is the use case for adding the server version? > > I can imagine something like wanting to know exactly where the dump came > from, but then host name and such would be better. (And then you can > infer the server version from that.)
I added this ToDo because we had a case where we were spelunking through some old pg_dumps, and the provenance was sufficiently distant that we couldn't readily infer what PostgreSQL version was involved. If pg_dump reported something like: -- pg_dump version: 8.5_devel -- postgres server version: 8.4.17 then it would be trivial to ascertain the information. Actually, I have no argument with your point; perhaps a whole "header section" is the right answer: -- pg_dump version: 8.5_devel -- postgres server version: 8.4.17 -- dump began at: 2010-07-01 14:22:27 EDT -- server name: wolfe -- more, maybe? >> Another issue is that it's not all that clear what to do or how to do it >> for archive dumps --- do you then want both pg_dump and pg_restore to >> tell you about themselves? > > I don't see a good reason for pg_restore to get involved. Agreed. This isn't needed for pg_restore to do anything better; it's so that humans can do better "archaeology." -- let name="cbbrowne" and tld="acm.org" in name ^ "@" ^ tld;; http://linuxfinances.info/info/languages.html Rules of the Evil Overlord #187. "I will not hold lavish banquets in the middle of a famine. The good PR among the guests doesn't make up for the bad PR among the masses." <http://www.eviloverlord.com/> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers