X-Original-To: pgsql-sql@postgresql.org
Received: from localhost (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with ESMTP id 6B043474E4F
	for <pgsql-sql@postgresql.org>; Wed, 26 Feb 2003 16:09:24 -0500 (EST)
Received: from postgresql.org ([64.49.215.8])
	by localhost (postgresql.org [64.49.215.8:10024]) (amavisd-new) with
	SMTP id 42451-02 for <pgsql-sql@postgresql.org>;
	Wed, 26 Feb 2003 16:09:13 -0500 (EST)
Received: from sss.pgh.pa.us (unknown [192.204.191.242])
	by postgresql.org (Postfix) with ESMTP id AAE1B474E42
	for <pgsql-sql@postgresql.org>; Wed, 26 Feb 2003 16:09:13 -0500 (EST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.12.6/8.12.6) with ESMTP id h1QL9E5u006289;
	Wed, 26 Feb 2003 16:09:14 -0500 (EST)
To: Tilo Schwarz <mail@tilo-schwarz.de>
Cc: pgsql-sql@postgresql.org
Subject: Re: Relation "pg_relcheck" 
In-reply-to: <200302262140.17578.mail@tilo-schwarz.de> 
References: <20030225155021.GA4347@pirmabanka.lv>
	<10992.1046190247@sss.pgh.pa.us>
	<200302262140.17578.mail@tilo-schwarz.de>
Comments: In-reply-to Tilo Schwarz <mail@tilo-schwarz.de>
	message dated "Wed, 26 Feb 2003 21:40:17 +0100"
Date: Wed, 26 Feb 2003 16:09:14 -0500
Message-ID: <6288.1046293754@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: by amavisd-new
X-Archive-Number: 200302/590
X-Sequence-Number: 11988

Tilo Schwarz <mail@tilo-schwarz.de> writes:
> Because this sort of questions appears quite often, I was wondering, if the 
> start up message of psql could be changed from 
>   Welcome to psql 7.4devel, the PostgreSQL interactive terminal.
> to something like
>   Welcome to psql 7.4devel, the PostgreSQL interactive terminal.
>   Connected to PostgreSQL <put version here>.
> to make it easier to catch these errors.

I'm not eager to add yet another hidden query cycle to the connection
startup overhead, especially not one that does nothing for people who
aren't making mistakes ;-).  What's been in the back of my mind is that
when we redesign the FE/BE protocol (real soon now, I hope) we should
extend the backend's first message to the frontend to include its
version number, as well as any other useful info we can think of
(database encoding and default client encoding come to mind).  This
would make it quite inexpensive to add the backend version to psql's
banner, as well as be a net savings in startup time now that libpq only
comes in a multibyte-enabled version.

			regards, tom lane