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?