Skip site navigation (1) Skip section navigation (2)

Re: First draft of new FE/BE protocol spec posted for comments

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Barry Lind <blind(at)xythos(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: First draft of new FE/BE protocol spec posted for comments
Date: 2003-04-23 23:08:57
Message-ID: 9278.1051139337@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-interfaces
Barry Lind <blind(at)xythos(dot)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


In response to

Responses

pgsql-hackers by date

Next:From: Philip YarraDate: 2003-04-24 00:17:15
Subject: Re: ECPG thread-safety
Previous:From: Mike CastleDate: 2003-04-23 21:47:22
Subject: Re: default locale considered harmful? (was Re: Using index for "like 'ABC%'" type query)

pgsql-interfaces by date

Next:From: Philip YarraDate: 2003-04-24 00:17:15
Subject: Re: ECPG thread-safety
Previous:From: Sander SteffannDate: 2003-04-23 21:17:05
Subject: Re: First draft of new FE/BE protocol spec posted for comments

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group