pg.ddx.io  pgsql-interfaces@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Barry Lind <blind@xythos.com>
Cc: pgsql-hackers@postgresql.org
Cc: pgsql-interfaces@postgresql.org
Subject: Re: First draft of new FE/BE protocol spec posted for comments
Date: Wed, 23 Apr 2003 19:08:57 -0400
Message-ID: <9278.1051139337@sss.pgh.pa.us> (raw)
In-Reply-To: <3EA6D372.3000406@xythos.com>
References: <10770.1050448110@sss.pgh.pa.us>
	<3EA6D372.3000406@xythos.com>

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




view thread (12+ messages)  latest in thread

Message-ID: <9278.1051139337@sss.pgh.pa.us>
Permalink:  ../9278.1051139337@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/9278.1051139337@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-interfaces@postgresql.org
  Cc: tgl@sss.pgh.pa.us, blind@xythos.com, pgsql-hackers@postgresql.org
  Subject: Re: First draft of new FE/BE protocol spec posted for comments
  In-Reply-To: <9278.1051139337@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox