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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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

Browse pgsql-hackers by date

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

Browse pgsql-interfaces by date

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