Thread: psql, 7.4, and the \d command

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

Brendan Jurd <blakjak@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

Tom Lane wrote:

>Brendan Jurd <blakjak@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
>
>

> 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

On Tue, 17 Feb 2004, Tom Lane wrote:

> Brendan Jurd <blakjak@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