Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org
	(8.8.8/8.7.5) with ESMTP id KAA18099;
	Wed, 22 Jul 1998 10:43:41 -0400 (EDT)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA01874;
	Wed, 22 Jul 1998 10:43:23 -0400 (EDT)
To: t-ishii@sra.co.jp
cc: pgsql-interfaces@postgreSQL.org, hackers@postgreSQL.org
Subject: Re: [HACKERS] atttypmod now 32 bits, interface change 
In-reply-to: Your message of Wed, 22 Jul 1998 09:58:19 -0400 (EDT)
	<199807221358.JAA22860@candle.pha.pa.us>
Date: Wed, 22 Jul 1998 10:43:23 -0400
Message-ID: <1872.901118603@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

t-ishii@sra.co.jp writes:
>> I noticed that 6.4 client did not talk to 6.3.2 server.
>> Connection to database 'test' failed.
>> Unsupported frontend protocol.
>> 
>> I thought that we have kept the "backward compatibility" since we
>> introduced "protocol version" in libpq?

Backwards compatibility yes: a 6.4 server should be able to talk to
an old client.  You're asking about cross-version compatibility in the
other direction, which is something we don't have.  The connection
protocol is designed to let the server accommodate to the client, not
vice versa --- the client tells the server its version, but not vice
versa.  I suppose the client might check for that particular error
message after a connect failure and then try again with a lower version
number ... but that's pretty messy.

On a practical level, the new libpq is not capable of talking to an old
server anyway --- some of the cleanups I made are critically dependent
on new protocol features, such as the 'Z' (ReadyForQuery) message.

Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Might be my atttypmod changes.  I did not make those version-sensitive. 
> I will do that now.

Yes, if we want to have backward compatibility as I just defined it,
then the backend will have to send atttypmod as either 2 or 4 bytes
depending on ProtocolVersion.  Shouldn't be too hard.  But I'm concerned
that you and I both missed that initially.  We had better actually test
that the current backend sources will work with a 6.3.2-release frontend.

			regards, tom lane