On Fri, 2006-03-03 at 10:38, Sascha Nepper wrote: > >What's that "datpath" about? Is it a version problem? postgres (PostgreSQL) > 7.3.10-RH > > Just set up a new postgres on another server. Restoring my dump and then > trying pg_dump again. > > Here's the result: > > pg_dump mpv > pg_dump: server version: PostgreSQL 8.1.3 on i686-pc-linux-gnu, compiled by > GCC gcc (GCC) 3.3.1 (SuSE Linux); pg_dump version: 7.3.9 > pg_dump: aborting because of version mismatch (Use the -i option to proceed > anyway.) > > pg_dump mpv -i > pg_dump: server version: PostgreSQL 8.1.3 on i686-pc-linux-gnu, compiled by > GCC gcc (GCC) 3.3.1 (SuSE Linux); pg_dump version: 7.3.9 > pg_dump: proceeding despite version mismatch > pg_dump: SQL command failed > pg_dump: Error message from server: ERROR: column "datpath" does not exist > pg_dump: The command was: select (select usename from pg_user where usesysid > = datdba) as dba, encoding, datpath from pg_database where datname = 'mpv' > > I cannot understand why this "datpath"-thing happens again... :o( It's simple. Under 8.1.3 something was added to the database that the new 8.1.3 pg_dump knows about that the 7.3.9 pg_dump couldn't know about, because it was written a couple years before that had been added to postgresql, in 8.x (whatever version). It's quite reasonable to use a newer (i.e. higher version number) version of pg_dump on an older database, because it's fairly easy to incorporate backwards compatibility into pg_dump. But without time travel (not temporal database sets, but real, honest, get in a box and travel backwards in time) it's pretty hard for an older version of pg_dump to know how to handle future versions of postgresql, cause they didn't exist when that version of pg_dump was written. So, the version of pg_dump should be equal to or greater than the version of the postgresql database you are dumping, got it?
