psql, 7.4, and the \d command

[Brendan Jurd]

Hello all,

I just wanted to pass on some information about compatibility between
the psql client and the postgres server.

On a particular network, my workstation and the server are both debian
boxes, but the workstation is on a more frequent upgrade schedule. The
server is still running postgres 7.3.4, but my workstation has been
upgraded with the latest (7.4.1) postgres client tools.

Now, the workstation's 7.4.1 psql client is able to connect to the 7.3.4
server and execute queries quite happily, but when I tried to use the \d
internal slash command to describe a table, I got the following:

ERROR: Function pg_catalog.pg_get_triggerdef(oid) does not exist
Unable to identify a function that satisfies the given argument
types
You may need to add explicit typecasts

Since I didn't realise the difference in versions at the time, I had to
do a bit of digging to figure out what was going on. Considering the
actual cause of the problem, this error message was utterly unhelpful,
even slightly detrimental, since it made me suspect that my database was
missing some important internal function.

I'm not objecting to the incompatibility itself, but I do think more
information needs to be provided to the user. I humbly suggest that if
psql is not going to be fully backwards-compatible with previous
postgres backends, at the very least you should issue a warning when
psql connects to a partially compatible server. Something simple like ...

WARNING: psql version is 7.4.1, but postgres server version is 7.3.4.
Some psql features may not function as expected.

.... would do the trick nicely.

Thanks

BJ

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Tom Lane]

Brendan Jurd <bl*****@blakjak.sytes.net> writes:

I'm not objecting to the incompatibility itself, but I do think more
information needs to be provided to the user. I humbly suggest that if
psql is not going to be fully backwards-compatible with previous
postgres backends, at the very least you should issue a warning when
psql connects to a partially compatible server.
This has been discussed before. I think the reason for not doing it
has been the difficulty of coming up with a useful warning that explains
what will work and what won't. You suggest
WARNING: psql version is 7.4.1, but postgres server version is 7.3.4.
Some psql features may not function as expected.

but you've got to admit that's pretty vague and unhelpful.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Brendan Jurd]

Tom Lane wrote:

Brendan Jurd <bl*****@blakjak.sytes.net> writes:

I'm not objecting to the incompatibility itself, but I do think more
information needs to be provided to the user. I humbly suggest that if
psql is not going to be fully backwards-compatible with previous
postgres backends, at the very least you should issue a warning when
psql connects to a partially compatible server.
This has been discussed before. I think the reason for not doing it
has been the difficulty of coming up with a useful warning that explains
what will work and what won't. You suggest

WARNING: psql version is 7.4.1, but postgres server version is 7.3.4.
Some psql features may not function as expected.

but you've got to admit that's pretty vague and unhelpful.

It is vague, but it's not unhelpful. Especially not when contrasted
with the current behaviour -- where the application carries on as though
nothing is amiss. It at least gives the user some indication that weird
errors during the session may be related to incompatibility. It makes
the user aware of a version discrepancy, which could be a useful prompt
for him to bring the two versions into accord, if desired. It also
tells the user what version the server is running, which the current
psql fails to do -- it merely reports the client version.

It's not a catch-all solution, but it does have some benefits, and, as
far as I can see, no real downsides.
regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Mike Nolan]

> This has been discussed before. I think the reason for not doing it

has been the difficulty of coming up with a useful warning that explains
what will work and what won't.

I think all that is necessary is to expand the startup banner to show
what the back end is:

Welcome to psql 7.4.1, the PostgreSQL interactive terminal.
Connected to PostgreSQL 7.3.4 server[@host]

This is similar to what some other front ends (ie, Oracle) do.
it may not be all that helpful in terms of explaining what will and what
won't work, but it unobtrusively identifies the back end for those who
need or want that information.

I would only display the host information if psql was called with -h.
--
Mike Nolan

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[scott.marlowe]

On Tue, 17 Feb 2004, Tom Lane wrote:

Brendan Jurd <bl*****@blakjak.sytes.net> writes:

I'm not objecting to the incompatibility itself, but I do think more
information needs to be provided to the user. I humbly suggest that if
psql is not going to be fully backwards-compatible with previous
postgres backends, at the very least you should issue a warning when
psql connects to a partially compatible server.

This has been discussed before. I think the reason for not doing it
has been the difficulty of coming up with a useful warning that explains
what will work and what won't. You suggest

WARNING: psql version is 7.4.1, but postgres server version is 7.3.4.
Some psql features may not function as expected.

but you've got to admit that's pretty vague and unhelpful.

I'd rather something like:

WARNING: psql/pgsql client server version mismatch.
Things will break. You're on your own.

:-) At least it's honest
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match