psql 8.2 client vs pg 8.1 server problem

Started by Alban Hertroysover 18 years ago4 messagesgeneral
Jump to latest
#1Alban Hertroys
alban@magproductions.nl

We have psql 8.2 clients on our workstations, while we still have pg 8.1
on our development and production servers. This causes problems like the
following:

database> \d table
ERROR: column i.indisvalid does not exist
database>

We can log into the server and use the local client of course, but this
problem is causing some confusion among our new employees and doesn't
exactly inspire them with the reliability we know PostgreSQL has...

Is there a better workaround, or may this be a bug even?

Versions:

psql --version
psql (PostgreSQL) 8.2.4
contains support for command-line editing

database> select version();
version

---------------------------------------------------------------------------------------------
PostgreSQL 8.1.4 on x86_64-pc-linux-gnu, compiled by GCC cc (GCC) 3.3.5
(Debian 1:3.3.5-13)
(1 row)

--
Alban Hertroys
alban@magproductions.nl

magproductions b.v.

T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede

// Integrate Your World //

#2Dave Page
dpage@pgadmin.org
In reply to: Alban Hertroys (#1)
Re: psql 8.2 client vs pg 8.1 server problem

Alban Hertroys wrote:

We have psql 8.2 clients on our workstations, while we still have pg 8.1
on our development and production servers. This causes problems like the
following:

database> \d table
ERROR: column i.indisvalid does not exist
database>

We can log into the server and use the local client of course, but this
problem is causing some confusion among our new employees and doesn't
exactly inspire them with the reliability we know PostgreSQL has...

Is there a better workaround, or may this be a bug even?

Install the 8.1 version of psql on your workstations (and symlink it to
psql81 or something if necessary). psql doesn't make any promises about
backward compatibility - for that, you'll need to use something like
pgAdmin (even that may need to be pointed at the older versions of
pg_dump etc if you're going to run backups from the workstations).

Regards, Dave.

#3Alban Hertroys
alban@magproductions.nl
In reply to: Dave Page (#2)
Re: psql 8.2 client vs pg 8.1 server problem

Dave Page wrote:

Alban Hertroys wrote:

We have psql 8.2 clients on our workstations, while we still have pg 8.1
on our development and production servers. This causes problems like the
following:

database> \d table
ERROR: column i.indisvalid does not exist
database>

We can log into the server and use the local client of course, but this
problem is causing some confusion among our new employees and doesn't
exactly inspire them with the reliability we know PostgreSQL has...

Is there a better workaround, or may this be a bug even?

Install the 8.1 version of psql on your workstations (and symlink it to
psql81 or something if necessary). psql doesn't make any promises about
backward compatibility - for that, you'll need to use something like
pgAdmin (even that may need to be pointed at the older versions of
pg_dump etc if you're going to run backups from the workstations).

But wouldn't it suffice to issue the "old" versions of the command
queries on an "old" server? It shouldn't be that hard to keep backward
compatibility among minor versions of psql. Even the server version is
known... They're just queries, right? How hard can it be to keep various
versions around so as to match the server version?

I can understand that new psql client features wouldn't be backward
compatible, but normal commands like \d should keep working.

--
Alban Hertroys
alban@magproductions.nl

magproductions b.v.

T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede

// Integrate Your World //

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Alban Hertroys (#3)
Re: psql 8.2 client vs pg 8.1 server problem

Alban Hertroys <alban@magproductions.nl> writes:

But wouldn't it suffice to issue the "old" versions of the command
queries on an "old" server? It shouldn't be that hard to keep backward
compatibility among minor versions of psql.

It's enough of a pain in the neck that no one has bothered ...

regards, tom lane