To: Barry Lind <blind@xythos.com>
Cc: pgsql-hackers@postgresql.org, pgsql-interfaces@postgresql.org
Subject: Re: First draft of new FE/BE protocol spec posted for comments 
In-reply-to: <3EA6D372.3000406@xythos.com> 
References: <10770.1050448110@sss.pgh.pa.us> <3EA6D372.3000406@xythos.com>
Comments: In-reply-to Barry Lind <blind@xythos.com>
	message dated "Wed, 23 Apr 2003 10:54:58 -0700"
Date: Wed, 23 Apr 2003 19:08:57 -0400
Message-ID: <9278.1051139337@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Barry Lind <blind@xythos.com> writes:

> The Bind message contains a field for the typlen of the parameter value. 
>   This field as documented signifies null with the special value of 0. 
> This implies that there cannot be any datatype that allows an empty 
> value to mean something other than null, as there would be no way to 
> distinguish null from a value that was 0 bytes long.

No, typlen is the value from pg_type.typlen; there is no meaning to the
value zero in that column.  A variable-length datum that happened to be
zero bytes long would still be associated with a negative typlen.  A
fixed-length datum of zero bytes isn't real likely ...

> Why does the message EmptyQueryResponse still exist?  It is documented 
> as existing for "historical reasons".  Can't it be removed in a major 
> overhaul of the protocol like this?

I was ready to get rid of it and then realized that it has a use now.
With it, it's guaranteed that the response to Execute will end with
exactly one of these messages: CommandComplete, EmptyQueryResponse (if
the portal was created from an empty query string), ErrorResponse, or
PortalSuspended.  Without it, we'd need to invent some other message
to signify the end of an Execute cycle.

> My final question is more of an implementation question than comments on 
> the protocol itself.  Since the jdbc driver needs to be backwardly 
> compatible with 7.3 and earlier servers that will speak the 2.0 
> protocol, what is the recomended way to write the client so that it can 
> 'detect' which protocol to use.

I'd do it the other way: send a 3.0 connection request and then, if you
get a "bad protocol" error response, send a 2.0 connection request.
You do have to be a little careful about parsing the connection response
since if it's 'E' it might be either 2.0 or 3.0 layout, but that can be
handled without too much difficulty I think.  (Look at the
already-committed code in libpq's fe-connect.c.)

			regards, tom lane