Sender: phil
Message-ID: <354796A9.3AE74910@river-bank.demon.co.uk>
Date: Wed, 29 Apr 1998 21:07:53 +0000
From: Phil Thompson <phil@river-bank.demon.co.uk>
Organization: At home
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org
Subject: Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes
References: <7040.893780515@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:
> 
> PROTOCOL CHANGES:
> 
> We should change the protocol version number to 2.0.
> It would be possible for the backend to continue to support 1.0 clients,
> if you think it's worth the trouble to do so.

Or 1.1?  The changes don't seem too traumatic.  Either way, maintaining
support for 1.0 is important as not all of us use libpq and we need time
to catch up.  Also we don't want to put barriers in the way of companies
like Openlink who seem willing to provide support for PostgreSQL in
commercial products.

> 1. New message type:
> 
> Command Done
>         Byte1('Z')
> 
> The backend will emit this message at completion of processing of every
> command string, just before it resumes waiting for frontend input.
> This change eliminates libpq's current hack of issuing empty queries to
> see whether the backend is done.  Note that 'Z' must be emitted after
> *every* query or function invocation, no matter how it terminated.

The completion response already does this for successful queries, and
the error response for unsuccessful ones.  I came to the conclusion (but
not with absolute certainty) a while back that the empty query hack was
needed for an old feature of the backend that is no longer there.  From
looking at a dump of the data between psql and the backend for 6.3.2 I
don't think that those empty queries are issued any more.  I have
implemented a pure Tcl frontend that doesn't issue them and I haven't
seen any problems.

The exception to the above is the single empty query sent immediately
after the frontend has been successfully authenticated.  This is useful
because it has the side effect of checking that the user has privileges
against the particular database - it is better to do this as part of the
session set up rather than the first real query which may be some time
later.

> 3. The "Start Copy In" response message is changed from 'D' to 'G',
> and the "Start Copy Out" response message is changed from 'B' to 'H'.
> These changes eliminate potential confusion with the data row messages,
> which also have message codes 'D' and 'B'.

The context means there should be no confusion - but if the protocol is
being changed anyway then it makes sense to do this.

Phil