> Kettle developers think that binary data should be returned as byte[].
> They don't want to make any workarounds into their application to
> enable Firebird to read binary data correctly when other databases
> doesn't have this problem.

Quite logical... I can understand them. Since they use standard mapping
defined in the specifications. If you use BLOB data type, you'll get
byte[] when calling ResultSet.getObject(int) method. But BLOBs are more
expensive in terms of network access (additional roundtrips to the
server).

> If you cannot change default behaviour of JDBC driver, can you change
> it when some extra configuration option is set? Something like
> 'returnOctetsAsBytes' or whatever. When this option is set to true
> then JDBC driver could return CHAR/VARCHAR OCTETS as array of bytes. I
> hope it make sense.

I will think about it. Please add a feature request.

Meanwhile, I'd say that you simply subclass the FBDriver class, override
the methods of the AbstractConnection class that create instances of
AbstractStatement, AbstractPreparedStatement and AbstractCallableStatement
classes, and the methods of FBResultSet class.

It may sound complicated, but that is few hours of work. But you will get
your custom version of driver that you can adapt to your needs.

> Or at least, when I set parameter encoding=OCTETS, all CHAR/VARCHAR
> should be returned as byte[]. As I tested, OCTETS is not allowed to be
> set for parameter encoding now. Is there any reason for this?

I see no reason for not allowing OCTETS in the connection string. I will
check it after my vacations. Please add this as bug report.

Roman