FE/BE Protocol 3.0 Draft - Some Comments - Mailing list pgsql-interfaces

I looked at the new draft protocol document, and it looks pretty good. I
have no real problems with anything, but just some comments. (Wouldn't want
you to think nobody is reading your stuff.)

1) I think the ErrorResponse message is way too complicated. I realize the
previous format (just an error string) wasn't good enough, and you need
error codes and such. But the current v3 message spec calls for parsing out
an indefinite number of up to 10 different sub-types (3 required, 7
optional), and I don't see the need for this complexity. What if something
goes wrong while parsing an error message?  Would you consider something
simpler, like:  Byte1('E'), Int32 length  - The standard message header  Byte1 Severity: one of E F P W N D I L for
ErrorFatal Panic...  Byte5 Code: the SQLSTATE  String Message: Human-readable message, suitable for showing the user.
 
To me, the other fields are not useful to most of us (file, linenumber,
call-stack traceback), overkill (detail), or silly (hint).     > SELECT * from MYTABEL;     ERROR:  Relation "mytabel"
doesnot exist     Hint: Learn to type.
 

2) Please don't deprecate FunctionCall, nor say that a prepared "SELECT
function($1)" can replace it. What about sending binary data to the backend
(without having to escape it)? Is there some other way than FunctionCall?
How would the large object interface work without FunctionCall?

3) There is still no way to pass NULL as a FunctionCall argument; now is
your chance to fix it if you want to. Not that I've seen a need for it.

4) Is there a good reason to continue having DataRow's field size value
include itself, but BinaryRow's field size value not include itself? It
bothers me that these two messages have identical syntax except that the
size value is +4 in DataRow. For the record, I prefer to have lengths not
include themselves. This applies to the new overall message length.
See: type = read_byte(); length = read_int32(); message = read(length-4);
That -4 seems unnecessary.

5) Backward compatibility: Realizing that the primary focus will be
V2 clients talking to V2/V3 servers ("upgrade your servers before your
clients"), it would still be nice if V2/V3 clients could talk to a V2 server.
I see a problem here. The V2/V3 client writes a V3 startup packet to the
server, and the V2 server responds with an error "FATAL:  unsupported
frontend protocol" and closes the connection. OK, the client can then
retry connecting with V2 protocol. The problem is that the error message
from the V2 server is in V2 format: byte1('E'), String Message. The
V2/V3 client will be looking for a V3 error message: byte1('E'), int32
length, ... If the client separates "reading the message" from "parsing
the message", it hasn't got a chance. This would have to be special-cased,
like relying on length = 0x46415441 (this is 'FATA'). Is there a better way?