> > This should be done without problem, because I added binary parameter to
> > Connection and Datasources, so user can decide to use binary mode
> > retrieve or current text mode (default). Currently I implemented
> > retrieve of short, int, long, date and BigDecimal. Other simple and
> > basic types, used in typically application I will implement shortly.
>
> One of the difficulties in the existing patch is knowing when to request
> binary transfer and when to request text transfer because for the first
> execution the datatypes are not known. How have you addressed
> this problem?
Hm... I've done only binary retrieve. I can think wrong, but I probably read
and I didn't inspected this, but after you bind statement you can't change
mode (binary / transfer) of parameters, so _probably_ in prepared statement
will be inpossible to call setInt(1, val), and on 2nd call setString(1,
stringVal) - not sure.
About requesting binary transfer I assumed this
1) user sets binary for it's own responsibility (he must test application, and
there is nothing special in this, because PG supporrts too many and special
types, eg. inet address), so for example assuming that "scientific user" will
be able to use it's own types may be wrong.
2) i request all result parameters to be in binary form, i decided to write
parsers for all supported types :) with following code
if (isBinary()) {
pgStream.SendInteger2(1);
pgStream.SendInteger2(1);
}else{
pgStream.SendInteger2(0);
}
///Orignal code from QueryExecutorImpl.sendBind
pendingBindQueue.add(portal);
if (bindException != null)
{
throw bindException;
}
so yours way is better.
Regards,
Radek
