> Hmmm maybe I should read before sending. It appears that both input,
> and output can be text. The only catch with output is that you have
> to do a describe first to get the types. This may negate any gains on
> small result sets, but certainly for large ones it would help.
Disclaimer: this is my first real trip through the v3 protocol and the
JDBC driver source in general. So take anything below with several
grains of salt.
As far as I can tell from reading the JDBC CVS code, the sequence for
preparing and executing a statement for the first time is:
PREPARE (name=my_statement)
DESCRIBE STATEMENT (name=my_statement)
SYNC/FLUSH
Read Responses
BIND (portal=my_portal)
DESCRIBE PORTAL (name=my_portal)
EXECUTE (portal=my_portal)
SYNC/FLUSH
Read Responses
So it seems that we could do all text, mixed or all binary parameters
without adding a round trip, because we already do an extra round trip
when a statement is first prepared and we already know all of the
parameter types.
We could do all text or all binary outputs without adding a round trip
as well, because you can globally set the output format, but to do mixed
outputs we'd need to execute the DESCRIBE PORTAL to get the return
types, and then (not sure?) execute BIND again with different format
parameters?
-- Mark Lewis
