Thread: Should clients warn in case of server version mismatch ?
Hi, We connected psql 8.2.0 accidently to postmaster ver 8.1.5. \d tablename does not work. should psql at least warn like pg_dump does in case of such client server version mismatches ? regds mallah.
"Rajesh Kumar Mallah" <mallah.rajesh@gmail.com> writes:
> We connected psql 8.2.0 accidently to postmaster ver 8.1.5.
> \d tablename does not work.
> should psql at least warn like pg_dump does in case
> of such client server version mismatches ?
Um, did you read the banner?
$ ~/version82/bin/psql -p 5581 regression
Welcome to psql 8.2.0 (server 8.1.5), the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
WARNING: You are connected to a server with major version 8.1,
but your psql client is major version 8.2. Some backslash commands,
such as \d, might not work properly.
regression=#
regards, tom lane
On 12/8/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Rajesh Kumar Mallah" <mallah.rajesh@gmail.com> writes: > > We connected psql 8.2.0 accidently to postmaster ver 8.1.5. > > \d tablename does not work. > > should psql at least warn like pg_dump does in case > > of such client server version mismatches ? > > Um, did you read the banner? > > $ ~/version82/bin/psql -p 5581 regression > Welcome to psql 8.2.0 (server 8.1.5), the PostgreSQL interactive terminal. > > Type: \copyright for distribution terms > \h for help with SQL commands > \? for help with psql commands > \g or terminate with semicolon to execute query > \q to quit > > WARNING: You are connected to a server with major version 8.1, > but your psql client is major version 8.2. Some backslash commands, > such as \d, might not work properly. Dear Sir, I am extremely sorry i was just going to apologize for the mistake. But i like the way pg_dump behaves , it refuses to work unless -i is specified. Actually my colleagues complained that \d is not working. I think they got the database prompt as they get everyday and did not notice the warning. ( even i missed to see the WARNING) Warm Regds mallah. > > regression=# > > regards, tom lane >
I had problem such this. I've got 8.1.3 client and 8.0.6 server. But psql 8.1.3 warned me, that some \? functions can not work properly. I've resolved this problem in very simply way. I got binary psql from 8.0.x and run. Psql program is a client program, that uses libpq library, so it is (I think) no difference until the libpq includes correct and enough routines to call them from psql. I've tested for example my own application compiled with 8.1.3 libpq on 7.4.8 libpq, or compiled with 8.0.7 on 8.1.3. But the not use functions, like \?. No problems. But the \? functions in psql are implemented (I think) in other way and are version specific, becouse the consttruction of information part of database is not compatible between versions 8.0.x and 8.1.x and 8.2.x (the first two numbers of a version are signifficant in this case). Brgds Adam Rajesh Kumar Mallah wrote: > Hi, > > We connected psql 8.2.0 accidently to postmaster ver 8.1.5. > \d tablename does not work. > > should psql at least warn like pg_dump does in case > of such client server version mismatches ? > > regds > mallah. > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match > >
On 12/8/06, Adam Radlowski <adamr@informatyka.gdansk.pl> wrote: > I had problem such this. I've got 8.1.3 client and 8.0.6 server. But > psql 8.1.3 warned me, that some \? functions can not work properly. I've > resolved this problem in very simply way. thanks. my problem is resolved as i mantain symbolic links to different pgsql versions in /opt/usr/local i just gave full path to psql binary of old version instead of psql. My concern was that it is quite likely that developers willl FAIL to see the warning if they are presented with the psql prompt despite mismatch of major version numbers. IMHO for major version mismatch psql should not present the user with a prompt at all as certain commands are most likely not work. Regds Mallah. I got binary psql from 8.0.x > and run. Psql program is a client program, that uses libpq library, so > it is (I think) no difference until the libpq includes correct and > enough routines to call them from psql. I've tested for example my own > application compiled with 8.1.3 libpq on 7.4.8 libpq, or compiled with > 8.0.7 on 8.1.3. But the not use functions, like \?. No problems. But the > \? functions in psql are implemented (I think) in other way and are > version specific, becouse the consttruction of information part of > database is not compatible between versions 8.0.x and 8.1.x and 8.2.x > (the first two numbers of a version are signifficant in this case). > Brgds > Adam > > Rajesh Kumar Mallah wrote: > > > Hi, > > > > We connected psql 8.2.0 accidently to postmaster ver 8.1.5. > > \d tablename does not work. > > > > should psql at least warn like pg_dump does in case > > of such client server version mismatches ? > > > > regds > > mallah. > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 9: In versions below 8.0, the planner will ignore your desire to > > choose an index scan if your joining column's datatypes do not > > match > > > > > >
"Rajesh Kumar Mallah" <mallah.rajesh@gmail.com> writes:
> IMHO for major version mismatch psql should not present the
> user with a prompt at all as certain commands are most likely
> not work.
The analogy you're drawing with pg_dump is faulty. There are at least
three good reasons for psql to be more forgiving of version mismatches
than pg_dump is:
1. pg_dump is commonly run noninteractively (eg, from a cron job) where
any mere warning will likely go unnoticed. So it has to raise a hard
error to get the DBA's attention. psql's backslash commands are far
less likely to be used noninteractively, and a failure is usually pretty
obvious to a human user.
2. pg_dump is critical: if it dumps an unusable backup due to not
understanding the system catalogs of a newer server, the DBA who needs
that backup later will be badly screwed. psql's backslash commands,
again, are not so critical.
3. psql offers a pretty decent amount of functionality even if some of
its backslash commands don't work, whereas a dump that is wrong is worse
than useless. So the use-case for operating with a version mismatch is
much wider for psql.
So I think we have the right tradeoffs in this regard now.
regards, tom lane
On Fri, 2006-12-08 at 09:16, Tom Lane wrote: > "Rajesh Kumar Mallah" <mallah.rajesh@gmail.com> writes: > > IMHO for major version mismatch psql should not present the > > user with a prompt at all as certain commands are most likely > > not work. > > The analogy you're drawing with pg_dump is faulty. There are at least > three good reasons for psql to be more forgiving of version mismatches > than pg_dump is: One more difference, pg_dump is backward compatible. i.e. you don't have to use the -i switch to run pg_dump v 8.1.x against pgsql v < 8.1 because pg_dump knows how to back up older version of the db on purpose. So, pg_dump is VERY forgiving going in one direction, as it should be, and very unforgiving going in the other, again, as it should be.