> > > > > Backing up a level, the purpose of the protocol extension mechanism is > to help us agree on the communication protocol -- that is, the set of > messages that we can send and receive on a certain connection. The > question for the protocol extension mechanism isn't "which types > should always be sent in binary format?" but "would it be ok if I > wanted you to always send certain types in binary format?", with the > idea that if the answer is yes it will still be necessary for the > client to let the server know which ones, but that's easy to do if > we've agreed on the concept that it's OK for me to ask the server for > that. And if it's OK for me to ask that once, it should also be OK for > me to later ask for something different. > > This could, perhaps, be made even more general yet. We could define a > concept of "protocol session parameters" and make "which types are > always sent in binary format?" one of those parameters. So then the > conversation could go like this: > > C: Hello! Do you know about protocol session parameters? > S: Why yes, actually I do. > C: Cool. I would like to set the protocol session parameter > types_always_in_binary_format=timestamptz. Does that work for you? > S: Sure thing! (or alternatively: Sadly, I've not heard of that > particular protocol session parameter, sorry to disappoint.) > > The reason why I suggest this is that I feel like there could be a > bunch of things like this. The set of things to be sent in binary > format feels like a property of the wire protocol, not something > SQL-level that should be configured via SET. Clients, drivers, and > connection poolers aren't going to want to have to worry about some > user screwing up the session by changing that property inside of a > function or procedure or whatever. But there could also be a bunch of > different things like this that we want to support. For example, one > that would be really useful for connection poolers is the session > user. The pooler would like to change the session user whenever the > connection is changed to talk to a different client, and it would like > that to happen in a way that can't be reversed by issuing any SQL > command. I expect in time we may find a bunch of others. > >
Ok, this looks like the way to go. I have some questions about implementation. Client sends _pq_.format_binary server doesn't object so now the client implicitly knows that they can send a new protocol message. At this point the client sends some new message 'F" for example, with OID's the client wants in binary for the remainder of the session. Ideally, I'd like to avoid this second message. Is the above correct ? Dave
