Thread: Should clients warn in case of server version mismatch ?

Should clients warn in case of server version mismatch ?

From
"Rajesh Kumar Mallah"
Date:
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.

Re: Should clients warn in case of server version mismatch ?

From
Tom Lane
Date:
"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

Re: Should clients warn in case of server version mismatch ?

From
"Rajesh Kumar Mallah"
Date:
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
>

Re: Should clients warn in case of server version mismatch

From
Adam Radlowski
Date:
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
>
>


Re: Should clients warn in case of server version mismatch ?

From
"Rajesh Kumar Mallah"
Date:
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
> >
> >
>
>

Re: Should clients warn in case of server version mismatch ?

From
Tom Lane
Date:
"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

Re: Should clients warn in case of server version mismatch

From
Scott Marlowe
Date:
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.